At a recent Scrum gathering Ken Schwaber and Jeff Sutherland spoke about Technical and Design Death. Although the concepts themselves are not new , Ken and Jeff have identified a number of characteristics of which (I believe) are original insights. In addition to talking about the characteristics of Technical and Design Debt, they also outlined some useful graphs that a company or department could use to indicate the “health” of their software products.
I was originally going to write an article that discussed what the graphs indicated and the data required to construct them. In order to do that I wanted to reference articles that illustrated Ken and Jeffs ideas. I search the web without much success. Finally, I decided that I needed to write both an introduction and a follow up article. This is the introduction and discusses the concepts of technical debt, design death and their characteristics.
The road to Hell is paved with good intentions
Over the course of developing a project it is tempting for an organization to become lax regarding software quality. This may be for a number of reasons; the primary ones being that the team is expected to complete too much functionality in the given time; or quality is not considered a high priority characteristic of the software.
Let us consider a contrived example with a mythical “average” project team that’s currently working on the company’s flagship product. Lets assume that they are not making as much progress as originally envisioned.
Senior management will want to know why the teams progress has not been up to expectation. Subtle pressure can be brought to bear in order to bring the project in on time. The project manager explains the difference in timeframes by saying that “the project team have learnt be more efficient”. This is not really what happened. What really happened is that the project team reduced the quality of the software. The difference between what was delivered and what should have been delivered is described as technical debt.
Now lets consider the next project built on the same code base. They have exactly the same issues with regard to delivering software on time. But this time, they also have the additional disadvantage of working in a code base that is of a poor quality. Their progress is even slower than the first teams. Again the same management techniques that worked so well last time are used and pressure is again brought to bear on the project team. They finish “on time and within budget”, but weren’t nearly as “effiecient” as the first team. What’s happening now is that a layer of cruft is built upon a layer of cruft.
Technical Debt & Design Death
1. An unpleasant substance. The dust that gathers under your bed is cruft; the TMRC Dictionary correctly noted that attacking it with a broom only produces more.
2. n. The results of shoddy construction.
– Jargon File 4.2.0
The concept of software complexity as debt was originally coined by Ward Cunningham in an experience report for OOPSLA ’92 . It has since gained a large following and has been expanded to include Technical Debt  and Design Debt  in addition to other concepts.
Technical Debt is simply deferred work not directly related to new functionality but necessary for the overall quality of the system . Examples of this include:
- Delaying upgrades to necessary tools and frameworks,
- Delaying re factoring overly complex system components, etc.
If this technical work is necessary for the health of the system, then what happens when it’s ignored for too long? What happens when there are several layers of cruft and no unit tests to aid refactoring?
Recognizing Technical Debt & Design Death
Fast forward two years; the companies flagship product is now on it’s fourth version. It is significantly expanded in scope since the original, and is very, very complicated. So complicated in fact that there are sections of the code that only one or two developers in the entire company have the ability to make changes to it. Classes may be several thousand lines of code.
True story: I was recently at a client who described their classes being very complicated. I asked them, “How long are your classes? Three or four thousand lines?” The client staff all burst into laughter. I was puzzled by this so I asked what was so funny. “We’re lucky if our classes are three of four thousand lines … try ten thousand lines, plus!”
At this point the effort required to change any part of the code is significant and for all intent and purposes the code can be described as Design Dead. Ken has identified three attributes of code that has entered Design Death:
- The code is considered part of a core or legacy system. The functionality is interconnected to so many other parts of the system that it’s impossible to isolate (and hence reduce) any one component.
- There is either no testing, or minimal testing surrounding the code. This is really tautology by implication. Without comprehensive unit tests it is impossible to refactor the code to a more manageable state.
- There is highly compartmentized knowledge regarding the core/legacy system, and it may be supported by only one or two people in the company.
Knowing all this information is all very interesting, but how does it help a company? How does this information help companies that have a significant number of legacy systems? What options does it provide them? That was the subject that I originally set out to discuss and will now be part 2.
 Here is Ward Cunningham’s OOPSLA ’92 Experience report that draws the comparison between complexity and debt.
 And here’s the c2 wiki definition of Complexity As Debt, Technical Debt and Design Debt.