Creating Mountains of Technical Debt in Lean Startups

by Joris Poort

Lean methodology values employing minimal effort to get to the next milestone.  Lean principles have a short-term focus to test hypotheses, which is quite rational considering that once a hypothesis is disproven you haven’t wasted any time in further wasted effort.  Customer development methodologies also encourage similar principles, ensuring a deep understanding of the customer and the market before embarking on the development of an expensive product that nobody wants to buy.  These lean principles and culture will work great in optimizing the path to get initial traction, but could wreak havoc on further development of the product causing avoidable risks down the line.

Creating technical debt through minimizing waste

Specifically in software development, lean product development can result in significant technical debt.  To be sure, technical debt refers to the costs associated with hasty software development resulting in neglecting architecture, incomplete testing, and incomplete documentation.  Subsequently, once a product has accumulated technical debt, further development work contains interest payments on this debt in the form of building on code that still needs further work to truly be complete.  In the future, this debt can be paid off through rewriting the code in the right architecture as intended, completing all the testing necessary, and completing documentation.  Acquiring technical debt, in fact, is often a direct result from applying lean principles, since activities that do not add immediate value to achieving the next milestone in a product release should be considered waste. 

Vicious cycles of technical debt

The issue of technical debt accumulation is further compounded by the fact that once technical debt has been accumulated, cost-benefit analysis will often show that paying off the debt creates value in the long term, but destroys value in the short term – thus a bad decision if you are choosing the most efficient lean path to the next milestone.  This vicious cycle of technical debt accumulation can result in large amounts of increasing debt overhang, causing significant amounts of interest payments that significantly hinder and potentially stall further development.  The vicious technical debt cycle is analogous to taking out increasingly higher rate credit cards to pay off previous debt accumulated; you keep buying yourself a short term lifeline at an increasingly higher long term penalty.

Symptoms of technical debt are hard to identify

While a great developer with intricate knowledge of the code can provide a decent estimate of technical debt, this debt is often hidden and unknown to higher management.  The symptoms of technical debt are very hard to identify.  A development cycle with large technical debt interest payments results in development delays that often can’t be attributed to anything in specific, typically unfairly blamed on the miscalculation of estimated development timelines.  Subsequent decisions made based on a misunderstanding of technical debt situations can lead a startup astray – resulting in anything from slight misallocation of resources to cutting off potentially profitable product lines.  In situations where technical debt is the root cause of development delays, misinterpretation by management can result in severely misguided decisions.

How to really stay lean

Using lean methodology as a guide, product development timelines and decisions should be made balancing the optimal short term solutions with an awareness of the long term consequences.  There is nothing wrong with accumulating technical debt, in fact similar to financial situations, acquiring some debt to attain certain milestones more quickly can certainly result in value creation.  But be mindful of the longer term risks involved and addicting qualities of debt, a vicious cycle of technical debt can create a house of cards that will sooner or later come crashing down.  Early investments in good software architecture, testing, and documentation create higher cost and minimal benefit in the short term, but can pay huge dividends in the long term.

Some tips on how to avoid acquiring mountains of technical debt in a lean startup:

• Ensure management has a clear understanding of the level of technical debt
• Balance the short term needs for technical debt creation, with the longer term benefits of paying it off
• Understand the large shadow cast on software development by architecture, testing, and documentation

ADDENDUM

Response to comment below by Tristan

Tristan,

Thanks for the feedback – let me further explain and clarify how I’m thinking about the topic, hopefully the following addresses your concerns.

Also, while I am an MBA student, in full disclosure – I have two engineering degrees and worked in technical product development in entrepreneurial environments for over four years.

You correctly assert that there are many unknowns in the early stages of a startup.  At the extreme, when everything is unknown, you are right in stating that the best architecture cannot be known.  Lean startups are however all about focus on turning these unknowns into known facts as quickly as possible as you iterate from customer feedback.  Thus, I would argue that the unknowns should be quickly diminishing over time, especially in the early stages of a very lean hypothesis driven startup.  Secondly, many of the unknowns in startups are in fact “known unknowns” vs. “unknown unknowns”.  Known unknowns are ones that can be prepared for (unlike unknown unknowns) and taken into account in the architecture to ensure flexibility as necessary.  Lastly, even in the case where you have many unknowns there is still a big difference between “quick and dirty” coding to get the job done and code that has been well architected upon which it is easy to build and iterate further.  Regardless of a complete understanding of where the product is going, there are still significant architectural features that can be made within the code to allow for faster feature creation and iterative improvement.

With respect to testing and documentation, in both cases the threshold for what is required to do a good job is significantly beyond that required to develop code that works.  If there is significant pressure to release early and often, which there should be in a lean startup, the necessity of doing a decent job on testing and documentation the first time around is low while the pressure to release is very high.  As hypotheses become validated and the code base becomes more mature, the technical debt created in obsolete code is naturally eliminated, but the technical debt in the code base needs to be evaluated to be paid off to increase developer efficiency going forward.

My perception is that complete code rewrites are much more uncommon than you assert, and the decision to completely rewrite 2.0 could spell complete disaster for startups.  The list of things that can go wrong is extensive:  Chad Fowler states rewrites take longer, are harder, and more failure-prone than expected.  Jamie Zawinski’s experience should give you pause before rewriting.  David Hansson says its experience rarely a good idea and often ends in failure.  Joel Spolsky says its the single worst strategic mistake that any software company can make.  Steve Blank says its startup suicide.  I rest my case.

I am not proposing development of a “perfect architecture” like you mention, rather a more reasonable balanced approach to consider both the short term and long term impact of decisions to pay off the technical debt or carry it forward.  The more conversations management has with the engineering team, the better these issues can be surfaced and resolved.  Technical people certainly should have the best insight on measuring the quantity of debt, but I disagree with the notion that the decision on what to do should lie purely in the hands of the technical team.  The amount of technical debt carried forward at key decision points concerns all areas of the organization and the final decision to pay it off or carry it forward should be made taking all stakeholders into account at the higher management level, in the case of early stage startups, probably the CEO.

Best,

Joris