By Brad Cross - 2 July 2008
Technical Debt is a metaphor conceived by Ward Cunningham to describe the costs and tradeoffs associated with quick and dirty solutions.
Netscape offers a compelling example of excessive technical debt. The commercial battle between Netscape and Microsoft's Internet Explorer (notably the anti-trust suit) is well known. But what about the technical side of the story? Let's look at market share over time and how it corresponds to technical events.
When the first widely used version of Internet Explorer 3 came out in 1996, IE's market share was 20% compared with Netscape's 80%. By the time IE 5 launched in 1999, it had 75% of the market. Here is what Wikipedia has to say about what happened during the 3 year interlude:
"The aging Communicator 4.x code could not keep up with Internet Explorer 5.0. Typical web pages had become graphics-heavy ... which Communicator struggled to render. The Netscape browser, once regarded as a reasonably solid product, came to be seen as crash-prone and buggy. In addition, the browser's somewhat dated-looking interface didn't have the modern appearance of Internet Explorer."
"In March 1998, Netscape released most of the code base for Communicator under an open source license. The product named Netscape 5, which was intended to be the result, was never released, as managers decided that the poor quality of Netscape's code made a complete rewrite their only viable option. ... [M]any users continued to migrate to Internet Explorer, and the Netscape browser itself has largely been abandoned."
Netscape 5 was never really released commercially, and by the time they released version 6.0, it had been about 3 years since the 4.0 release. The chart tells the story of what happened to their market share during those three years. What was happening technically? Why did it take them so long to release? They rewrote from scratch.
A team not committed to quality is a team with depreciating code base: technical liabilities steadily erode equity with a high cost of carry. As the code base grows without evolutionary design, refactoring and automated testing, it gets crufty, buggy and unreliable. New development slows dramatically because the code is difficult to change and extend. Releases become inconsistent and infrequent. Eventually, like Netscape, a team can go into technical default and face technical bankruptcy. At this point, most companies will enter into a re-write. The re-write, typically carried out by the same team that spearheaded the first catastrophe, is at high risk to fail as well. What has the team learned that will materially change the outcome?
The inverse can also be true: you can have a technical asset. Clean, well designed, modular code with appropriate test coverage can be easy to maintain and extend, and it can give you a platform to rapidly add new features even as your code matures and ages. You can easily swap out entire components of the system. This kind of code base can be a competitive advantage.
A technical asset can be a business asset, but not always. The code has to actually do something useful. Pretty code is not necessarily valuable code, and ugly code is not necessarily without value. Business value is orthogonal to the code.
This notion of usefulness might seem like a gray area, but look at the root word; use. Does anybody use the code to solve their problem? Do you have unused code in your code base? Delete it.
Technical debt, like financial debt, is not always a bad thing. Leverage can be used in moderation to increase returns. Sometimes you can go a bit faster and take on some technical debt. However, you must be mindful of the debt you take on and be prepared to pay it back.
It is questionable whether a team is faster or slower with technical debt, and where the balance lies. In the short term it may appear advantageous to take on technical debt to meet a deadline, yet it is obvious that it is necessary to minimize the debt burden in order to sustain a rapid pace over time. You can pay gradually during development, or you can make a lump sum payment by temporarily stopping the development of new features.
There are different grades of debt. High grade debt helps achieve a major deadline and can be paid off immediately - similar to low risk short term sovereign notes that pay low interest rates. If there is uncertainty in architecture or design, exploration is of greater value than inaction.
Low grade debt is risky and costly to service; the technical equivalent of "junk bonds." Still, even low grade debt might have its place. As a guiding principle: don't finance your core business on junk, and be wary of the fact that many so-called short-term solutions become long-term problems. Consciously taking on technical debt that will last beyond the life of a release cycle is likely to backfire. Avoid the myth of taking on debt that you will pay down later. Later will never come.
Are you rushing to meet a deadline, taking on technical debt at high interest rates? Will you be able to service that debt when your creditors come to call? Many teams aren't. Be mindful of your debt load, and know how and when you're going to service it.
About Brad Cross: Brad is a programmer.
No comments:
Post a Comment