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).

Tuesday, February 9, 2010

Is the industry moving away from Agile?

I don't think so.

I'm writing this in response to a link to this article on slashdot that a friend sent me asking the question which I've used as the title for this post. (The slashdot article references this blog post which is a good and informative read in itself and I found I agreed with many of his points. What starts as an emotional rant turns into a very well presented article.)

There isn't just one way of doing development or just one way of doing agile; hence the name agile. I thought the first poster on slashdot hit it on the head especially with his comments about having the right people and making adaptations to your business.

The author leads into the article complaining about agile but later talks about how many other methodologies can also be successful. The important thing in my mind is picking the right approach for the job (or team even; some methodologies only work with a certain type of people) and also understanding that methodology properly. In fact, the understanding must come first to be sure that you do pick the right approach for your team/project.

The author made a good point about how some people use the words "agile" and "scrum" interchangeably. It is my opinion that these are the teams that fail at agile. It could be that some see agile as being less structured and as a result end up thinking there are fewer rules and less accountability. An agile approach may give the developers more leeway and freedom but with that comes more responsibility. My experience has shown that a junior team usually cannot succeed in these circumstances. They typically will not have the experience required to make the design and implementation decisions that are usually made by someone else in a different model. It's been a challenge to overcome with some of our teams.

We use SCRUM outwardly but also take the XP approach mentioned by Kent Beck in "Extreme Programming Explained" and implement changes slowly. We reflect each week in our sprint retrospective on how those changes helped/hindered us and we also talk about new ideas and ways to improve our process. Yes, we follow a scrum model but one that we have adapted to our needs. We also know that it is more than just doing this list of things and then we'll have it right. We know that the business needs change, the business itself changes and that we need to be able to change and adapt in order to keep pace. I feel that with the right mix of people and support from management agile can be very effective.

Although we don't do game development where I work, I had previously found this pdf about lessons learned implementing SCRUM at Bioware and one of the key things I took from that was that they also ended up adapting SCRUM to their own needs. I think this is key to success with any methodology; being able to take what works and adapt where you need to.

Thursday, January 21, 2010

Setting up TortoiseGit to work with SSH on a different port (not port 22)

So recently we've had some headaches giving users on Windows machines access to our git repository (me being one of them but not the first). In searching for a solution to this problem I found several people with the same issue but having to use various workarounds or actually change their ssh port back to 22. All of the workarounds were out of the question for me but I knew there had to be a way to do it. Basically I just followed some of the better posts about using Git on Windows out there with a couple minor changes.

Here are links to a few of the posts I looked at while trying to figure this out:

The important pieces to make sure you get it working are these:
  1. Be sure you choose the OpenSSH option when installing msysgit
  2. Be sure you choose the OpenSSH option when installing TortoiseGit
  3. create a .ssh/config file and enter something like the following
Host name_of_host_where_your_git_repo_is
User git
Hostname name_of_host_where_your_git_repo_is
Port port_number
PreferredAuthentications publickey
IdentityFile "/path/to/your/openssh/private/key"
And you should be good to go. I actually set up msysgit and my ssh config file first, then I made sure that I could connect and then I installed TortoiseGit.

Tips:
  1. If you created your private key using puttygen then you'll need to export it (using puttygen) as an OpenSSH key.
  2. While testing your connection you can use ssh -v git@github.com (or @ your own host even) to see what ssh is doing and to make sure it is finding your key correctly.
  3. If your openssh key is located at C:\users\myuser\keys\key.ssh then the path to your IdentityFile should be like this: /c/users/myuser/keys/key.ssh