I’ve joined a new project recently. And they have a bunch of problems. The team consists of really smart developers, but over time, stress and too little focus on quality have seriously hurt their code base. Today, they are struggling to deliver at all.

ThoughtWorks has been invited to help them clean up a little of the mess. We’re working with introducing tests and clarifying their somewhat unclear design. At the same time, we’re being asked to not change the code unless it’s really important, because they’re merging branches of the code that split up years ago. Yes, I know this a Bad Thing.

I can’t help myself thinking that their problem is not in the design or the lack of tests. There is an underlying problem that no one seems to want to talk about. Tom DeMarco writes in his book “Slack”:

“In such an organization, there is a characteristic mantra that goes something like this: “Hurry up, hurry up, hurry up, hurry up, hurry up…”

When everyone in the team is constantly busy solving today’s problems, no one is preparing for tomorrow. If you think of software development as a cooperative game, not only do you have to make a move right now, you have to set up the board for the next move as well. If you fail to do this, you’ll be in trouble real soon. Of course, now and then it makes sense to take on technical debt, as long as you realise that sooner or later, you will have to pay, and probably with interest.

Sometimes, to continue building on a bad code base will only make the problem worse. At times like this, it’s good business to stop delivering at the same rate for a while, to be able to deliver even faster later on. It’s a tough discussion to have with the business, but a necessary one.

I’m not saying you should stop everything and refactor code for a few months. What I suggest is that you make high quality a primary concern, and delivering to a schedule secondary. Start introducing tests where you touch the code. Decouple as you go. Start having design discussions that involve everyone. Work on the teams communication skills – daily stand ups can help, as can retrospectives. You might want to start a design patterns study group to create a common language.

There are lots of things that can be done to improve how well a team works, but until you make a commitment to high quality, you won’t be able to make any lasting improvements.

Posted by Andres on Saturday, April 28th, 2007 at 11:54.