Technical Debt

With borrowed money you can do something sooner than you might otherwise. If you are willing to incur technical debt you can release a product earlier than you might otherwise.

We all recognize these stereotypes: The sales team is willing to (and sometimes do) sell a product and cash in the money long before development is finished. While the engineers are reluctant to let go of their baby because there are always things that can be improved. A successful business needs engineers and salespeople that are willing to compromise and cooperate on this conflict of interest. Technical debt is a powerful metaphor that can be used to work on a compromise, especially when we are talking about software development.

Technical debt in a software project includes internal things that you choose not to do now, but will impede future development if left undone [1]. Examples of technical debt might be: We need to upgrade our compiler to a more recent version, but let us ship the product now and upgrade the compiler later. We do not properly understand how to implement this feature properly anyway, but this hack seems to make the customer happy for now. We have identified some dirty code that is slowing us down, but we choose to fix it in the next release instead. These are all examples of prudent and deliberate reasons [2] for taking on technical debt which can be compared to borrowing money for sensible housing. There are also less responsible ways of incurring technical debt though, perhaps caused by; lust, gluttony, greed, sloth, wrath, envy or pride. Examples might include: writing bad code, skipping analysis and design, over-engineering, résumé-driven development and so on. This kind of technical debt is more like unauthorized overdrafts and check bouncing, and is best avoided if you have a long-term vision for your product.

Like financial debt, a technical loan will incur interests, and if you are not able or willing to pay back the loan then you risk go into bankruptcy. The nice feature of software however is that paying back is usually both possible and comparatively cheap. While making effective and strategic decisions about what internal qualities to postpone you should keep track of them and write down an estimated effort needed to do it properly. This will give you an idea of how much you owe at any point in time. Then, after rushing a release out of the door, you can immediately start to pay back by doing the postponed things properly and get a flying start into the next release. Retrofitting stuff like this might appear to be more expensive than “doing it right the first time”, but since we are dealing with software it is often the right approach.

Perhaps the most powerful feature of the Technical Debt metaphor is that it communicates well between technical and non-technical people [3]. By quantifying the current technical debt in your product it should be possible to get management both interested and involved in the importance of controlling the debt burden.

References:
[1] www.c2.com
[2] martinfowler.com
[3] blogs.construx.com/blogs/stevemcc

UPDATE June 2010: At Smidig 2009 and XP2010 I presented a talk titled “Technical Debt is Good!” based on this material. Here are the slides (pdf) that I used in norwegian and english respectively.

Software Architecture is a key enabler for your Business Strategy

Last month I organized an internal 4-day workshop in Software Architecture at my company. Twelve lead developers representing several product groups and development sites attended. The instructor was Dana Bredemeyer himself.

The workshop was excellent, although quite different from what I expected. Bredemeyers workshop was all about techniques for translating your strategy into architecture. Little was said about how to translate architecture into implementation, but that was ok. I have to admit that so far in my career I have thought about software architecture as something that first of all is useful for the implementation of software. But now I realize that for a business relying on complex software, focus on architecture is indeed a key enabler for your business strategy.

All software implementations have an architecture. By studying the code base and a running system you might be able to both illustrate the architecture and explain the expected behavior of the system. For many, perhaps most, development efforts this is a sensible way of working – apply most of your energy on writing code and just take a brief look at the resulting architecture at regular intervals to see if it makes sense. Let the user requirements drive the implementation, and use your test scenarios to verify the product. Because you will never get exactly what you plan for, the resulting product will determine which business strategy you can use to make money and the architecture will restrict how to evolve your business. The products drive the business (see figure 1).

For a business with only a few products on the market this can be a very efficient way of making money. Your product might be successful and the business attracts money that can be invested in making the same product even more fancy to attract even more money. Adjust your business strategy according to the products that are available.

However, as the business grows and the product portfolio diversifies, you need to focus more on architecture. Why? Because you might want a mechanism to let a strategy run the business, not the products. The key is to focus more on architecture so that you can drive it with your business strategy, and let the architecture strongly influence the implementation so that you get products that support the strategy. It is then possible to let a strategy drive your business (see figure 2).

Beware, I am not trying to tell you that heavy focus on architecture is the only way to succeed. It is certainly possible for huge businesses to experience massive success with large and complex software systems without paying too much attention on the architecture. However, the key point is that if you want to control your business by defining strategies you need to focus on the architecture – otherwise not much will happen if you position yourself inside the strategy bubble and try to twist the knobs.