Tuesday, July 6, 2010

Switching to PivotalTracker

For our SCRUM development we have used a variety of tools to plan and track our work.

Mingle
We used Mingle for a long time but found that because it is so customizable it makes it very easy to overcomplicate your project and process.  We also spent a large amount of time configuring, setting up and tweaking mingle to create the ideal project template.  Mingle is also very slow and seems to require a server with a huge amount of resources to run smoothly.

Scrum Ninja
Scrum Ninja has a lot of nice features and seems to be going in the right direction but it was very glitchy and we even lost some data at one point.  We were able to get most of it back through their support but it was definitely a hassle.  Searching didn't work very well and although the card wall view is a nice idea it can be hard to read.  The export format is relatively useless leaving out important data like dates.  It wasn't even worth trying to parse the exported text with a script to extract what we wanted.

Pivotal Tracker
Pivotal has done a very nice job with their Tracker product.  We first tried at the same time as ScrumNinja and first impressions left us feeling it was more restricted or had fewer features in some areas.  We gave it another go and now realize it has a much simpler interface that we've found frees us up to just work on the project rather than spending time setting it up in the tool.  It has several integrations with other projects and an open API for custom integrations.  We've also made suggestions and bug reports and had very quick responses and fixes.  It also uses csv as an export format.  All in all we're very happy with Tracker so far.  Plus, it's free.

overcomplicating things with the repository pattern

The Repository pattern was used in a project by some team members 6 or so months ago and it's being mentioned again along with concepts of an Aggregate Root in discussions on refactoring another project.  Both of these projects were C# projects using LINQ to SQL.   While working on the first project I kept thinking that the repository pattern seemed to just over complicate things and I couldn't see what real benefit it brought to a fairly simple application.  Now, I've done some further reading on Aggregate Roots and found ties to the repository pattern again.  As I read through several definitions I kept thinking that the main benefits are already provided via LINQ and implementing it on top seemed to only add another abstraction layer.  I did some more searching on the subject and found this article: Repository is the new Singleton and it just echoed everything I was thinking.

Creating a repository for data that is already in your DB is overkill when you are using LINQ (and likely any modern ORM) for accessing that data since the data access provided by LINQ is itself making use of the repository pattern .  A good place where the repository pattern would be useful is where you may have different sources of data.

Here is another interesting article about the Purpose of the Repository Pattern that talks about some of the issues when using this pattern along with LINQ.  The DataContext issues he mentions exist generally in a Web Application built on LINQ and not just when using repositories.  Our team got around some of the DataContext issues by using a DataContext Factory that we found that creates a scoped DataContext within the HttpContext and while within the scope of the HttpContext it always returns the same DataContext.  This helps keep anything within the HttpRequest in the same Unit of Work.  It was also written to work within the current thread if a HttpRequest is not available (a non-web app).