The Brink of Chaos

Development Debt

Development Debt

Imagine building a car, but starting with two bicycles. The first version would maybe have 4 big wheels, some sort of base and an engine. Of course, then we need better seats, and pretty soon some side panels, maybe throw in some cup holders?  It’s a rough ride so we put in shocks, a cd player, a transmission, lights, etc.  By the end, our “car” has a lot of features, but with every addition, the next things gets harder and harder to add. Now imagine we use this vehicle everyday to get to work, and if we don’t get to work on time, we’ll lose our job.  There is no time to take some time off, take the car apart and redesign it so the pieces fit together, there’s barely time just to keep it going.

This is the state of many software projects used every day to keep our world running.  It often starts with something useful, well designed and interesting.  This leads to more people depending on the tool, but also requires the tool to do new things, so they get bolted on.  Pretty soon it’s like our “bike-car”. Unfortunately, it is usually around this time that management decides that they can save money by reducing the number of developers, completely eliminating any possibility of making the overall system better.

The nature of development often requires us to take on debt in our software. We need to get something done so we cut a few corners and we get it out there for people to use.  It’s just like credit card debt. The first few purchases are not a problem, even if we don’t pay them off at the end of the month, but eventually we are paying more and more in interest and are unable to buy the new things we need.

Management needs to allow the developers to pay down the development debt and keep sufficient resources in the department to allow them to do that.  However, most managers have been burned by the perfect “rewrite”, where someone decides that they need to start over and instead of simply paying down debt and improving the product, they try to build the Taj Mahal of software projects to avoid ever having to do another rewrite. The project never delivers any value and often eventually gets killed. Management only has to be burned by this style of development once or twice before ever letting it happen again.

Building anything complex requires maintenance.  Maintenance doesn’t add immediate benefit, it prevents future failure. It’s something that every team needs to be able to invest in to keep things running.

Leave a Reply

%d bloggers like this: