Agility: Pair Programming & Quality

Written on 12:40:00 PM by S. Potter

I have been working on Agile development teams on and off over the last few years. Not all the "agile" teams I have worked on have been as disciplined as they really ought to have been, but I was wondering what agile developers thoughts are on effective pair programming practices? I know some of my ex-colleagues are quite happy with having one programmer glance at the other programmers code (after the other programmer designs and codes it by themselves) and write tests to see how to break the code, but I am not sure this is good enough for the sake of quality. I personally enjoy working with developers at all levels of experience assuming they are positive, friendly people or at least professional. Now I also know a number of developers that don't fit the "positive", "friendly" or "professional" molds, so I was wondering how to handle those situations effectively without compromising the software's quality early in the process. At the end of the day I am focussed on delivering high-quality software to clients because my job is on the line if I screw up and also my bonus depends on it, even if I don't screw up. The company I presently work at, Finsignia LLC, is more disciplined about agile principles than other organizations I have worked at previously. In fact, Finsignia is the only company I have worked for that specifies, in their contracts with clients, quantitative measures or ranges to define the level of software quality we will deliver to the client. For example, > 98% unit test coverage, SMI ranges, etc. Quantitative measures are even more important for the project/developer leads (which I am one). While we have a lot of automated tools that we incorporate into our continuous integration processes to measure our quality quantitatively, I don't like that thought of having to refactor something later when it should have been caught earlier on in the process. Presently the developers on my team have a blast, but I know at times people just can't get along in a positive way for various reasons. So I would appreciate any wisdom from people who have had to deal with this type of situation. I invite you to leave me your pearls in comments to this blog.

Trac and Alternatives

Written on 11:41:00 AM by S. Potter

I have been using Trac to help organize my development projects for about 6 months now and quite happy with it. I haven't yet found an alternative that can help small teams work more efficiently on agile projects.

So I would be interested to know if anyone out there presently uses something like Trac, which could be open source, free or commercial or even in-house proprietary software to help organize agile software projects? What is it you like about the products you use and why?

I would summary my experience with Trac as follows:


  • Easy to use
  • Simplistic and organic organization
  • Great to have integration of changeset views and comments, tickets and even wiki pages


  • Missing user story aspect of project audit
  • Lack of linking between milestones, components or versions


Written on 10:53:00 PM by S. Potter

Basecamp project management and collaboration I just signed up for a free BaseCamp account. This is the web application that generated a lot of buzz last year because it was developed by Ruby on Rails (RoR) creator David Hansson, while he was developing RoR. BaseCamp is supposed to be a web-based project management tool. However, after watching David's talk at Roskilde (on I guess "project management" is too much of a supercharged phrase to be applied to this web application. David also seemed to imply that it is more of an application to aid collaboration rather than manage it. I thought it would be completely amazing considering all the hype. Currently I am only luke warm on the product, but perhaps I need to use it more before I really start to like it. Up to now this is what I have noticed.


  • Nice design
  • Nice AJAX usage (mostly)


  • Waay too simplistic
  • Not enought functionality