A blog about the joys and perils of software development

Sustainable Software Development, Part 1: Managing Technical Debt

Software projects sometimes go bad. The pace of development is not sustainable. To achieve sustainable software development, we need to keep our focus on what’s important: the long-term health and maintainability of our source code.

Robert Martin has written a nice article on Scrum projects, and how applying Scrum often start out with hyper-productivity. However, most projects slow down when code size increases. After a while, we might even experience that progress approaches zero as time approaches infinity (if the project is not discontinued before it :).

Why is that? Martin lists a number of activities that are well-known to the experienced developer, such as unit testing, continuous integration and code coverage measurements. Most developers would even agree that applying them will help retaining productivity over the long run. Still, the law of least resistance often takes us down a different path. A strong focus on feature growth is very seductive, as it makes everybody happy in the short term: the customer is happy about their new features, the product owner is happy when he can satisfy the market and the team is happy when everybody commends them for their work. At least for a short while. The lack of focus on quality (such as a lack of automated unit tests and a poor continuous integration setup) will catch up with you.

Technical debt are the things you know you must do but haven’t done yet: fixing a bug, adding more unit tests, refactoring, cleaning up etc. Just as normal debt, it has to be payed back. No surprise there. Unfortunately, just like a normal debt, technical debt also come with an interest rate. You pay interest every time you say “aargh, this would have taken me ten minutes had I refactored this module” or “aargh, I just spent half a day tracking down a problem caused by a known bug”. Discussing, planning or thinking about what must be fixed is paying interest. Soon, your house belongs to the bank. Software development like this is not sustainable – it will come to a halt.

To avoid this, and to achieveĀ sustainable software development, we need to keep our focus on what’s important: the long-term health and maintainability of our source code. Just like the debt analogy, there’s a savings analogy. Invest some money in a savings account (or the stock market), and you will receive interest instead of paying. As a start, it is necessary to make an investment in good practices: fix things now, and use tools and techniques to ensure quality. You will be able to deliver new features for a long time and your velocity will stay high, or even increase over time.

This entry was posted in Personal Development, Software Development and tagged , , . Bookmark the permalink.

4 Responses to Sustainable Software Development, Part 1: Managing Technical Debt

  1. Niklas says:

    I would like to recommend this episode of Software Engineering for people who want to learn about sustainable architecture: http://www.se-radio.net/2009/08/episode-142-sustainable-architecture-with-kevlin-henney-and-klaus-marquardt/

    • Johnny says:

      Hi Niklas. It was a while since I listened to SE radio, they have a lot of very nice episodes. I will have a look at the sustainable sw architecture. Thanks!

  2. David Rejdemyhr says:

    I agree fully yo this. Unfortunately these arguments are used too often to avoid agile methods. Instead it should be seen as important knowledge to respond to by for example setting clear definition of done per user story to support always green lights

    • Johnny says:

      Hi David! Long time, I hope all is good! :)

      I’ve seen it happen too. Instead, people should see things like “fix it now” and “ensure quality” as the only acceptable attitude for a professional software developer. Agile or not, we need professionalism.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>