The Technical Debt Metaphor

    I love metaphors. Metaphors help me better understand an abstract idea. Software development is filled with metaphors. One of the metaphors widely used in software development, albeit often misunderstood, is technical debt. Technical debt is a term coined by Ward Cunningham, you can hear what he has to say about it here. Technical debt is a metaphor that refers to a very particular problem. Making a decision when you have limited understanding of the problem domain, or making a decision that will speed up the development now, but might slow you down in future.

    Imagine I have a confusing module in my code. I wrote it early on in the development, when I had a limited understanding of the problem domain. It's been months and the module has been working fine without any sign of trouble. Now I have to add a new feature to it. I realize that while the internal quality of the module is good, it represents the limited understanding that I had. Adding the new feature will take me 5 days. If I refactor the module to represent my current understanding, I can write the new feature in 3 days, but refactoring it will take me another 5 days. I took a loan several months ago when I designed the module sub-optimally.

    Going into debt is not necessarily a bad thing when it brings value. The problem comes later when the accrued interest, so to speak, is slowing down the development. I have to consider whether to pay off the debt or not. If it is just this one feature that I need to implement, it makes more sense to implement it in 5 days and not spend extra time refactoring the module. If, however, I need to implement a second feature that will be easier to implement with the refactored module, I'll just pay my debt, refactor the module, and implement the two features for less time in total.

    Technical debt is a conscious decision. Robert C. Martin, a.k.a Uncle Bob, gives a great example of it. Imagine that I am developing an application, and I have to release it before the competition. Instead of creating a rich user interface, I might get a loan from the future development plan, and create a simple user interface for the first version. Creating a simple user interface takes far less time than creating a rich user interface. Releasing the application with simple user interface gives me the competitive advantage of being the first to the market. I, however, know that the simple user interface simply will not cut it in the long run. I will have to invest time in future to create a rich user interface. I will have to pay back my metaphorical debt.

    Going into debt is no excuse to reduce the internal quality. While I am developing the simple user interface I still have to be professional. I know that I will change it in future, and yet I still have to write good, clean and easily maintainable code. Reducing the internal quality of the code will just make it harder, if not impossible, to move to the rich user interface. Technical debt does not mean poor code quality.

    What appeals most to me about the debt metaphor is that, as with a real loan, it suggests that I can pay off my technical debt gradually. I can plan small features and improvements to the simple user interface into every iteration. With each iteration I get closer to the rich user interface that I had initially planned. I don't have to pay the debt in one fell swoop. I can pay the interest first and the principal later. I can even restructure the debt and make new loans, if the need arises, although I am a practical man and I prefer not to spend more money than I actually have.

    Sometimes people neglect the internal quality and call it technical debt. They might have good understanding and still make a poor design choice in order to deliver a feature fast. The problem is that people often do not make an analysis of the cost of going into debt. They quickly build a code base that is hard to extend and maintain. This makes developing new features slower, which defeats the purpose of the loan. What's especially troublesome is that as debt piles up, it gets harder to pay it back.

    If the benefits of getting a loan outweigh its costs, it might be worth taking it. Not considering the costs and neglecting internal quality is a recipe for disaster. This puts you on the road to bankruptcy. To quote Uncle Bob: "A mess is not a technical debt. A mess is just a mess".


Popular posts from this blog

The Database is a Detail

    I've seen many applications where the database is in the center. In these applications the database is the most important part and everything else is just a shell around it. In most of the applications that I've seen, they use an ORM, and in some they use plain SQL. All of them had business objects without any behavior. All of the behavior, all of the business rules were in the database. I want you to think about that!      What's an "object" in the sense of object-oriented programming? What characterizes an "object " ? The first sentence in Wikipedia about object-oriented programming states: Object-oriented programming ( OOP ) is a programming paradigm based on the concept of " objects ", which can contain data and code : data in the form of fields (often known as attributes or properties ), and code, in the form of procedures (often known as methods ).      An object can contain data and code. In other words an object has data and
Read more

SOLID Series: The Single Responsibility Principle

     I am starting a series about the SOLID Principles of Object-Oriented Design. These are five principles that you should keep in mind when designing an object-oriented program. They are coined by different authors in different moments in time. You can say that they are hard learned lessons from the past.     Today I am going to write about the first of the five principles - The Single Responsibility Principle . It was coined by Robert C. Martin, a.k.a. Uncle Bob. The narrative usually goes along the lines of: "The SRP means that a class should do just one thing". I want you to think very carefully about this. I want you to think about it because it's a lie!     Imagine what a program made of classes which do just one thing would look like! I've actually seen such a program. The claim was that it conforms to the SRP, but nothing could be further from the truth! I'll spare you the details and I'll show you only the code that illustrates the point. I
Read more