(2009-07-30) Ries Embrace Technical Debt

Eric Ries says a Start Up should embrace Technical Debt. The biggest source of waste in new product development is building something that nobody wants... Most of us think we know a good design when we see it. Unfortunately, no matter how much up-front analysis we do, until the design is tested by actual practice, we can't really know... Leverage product development with open source and third parties (which have their own debt)... Given the choice between incurring technical debt in a particular end-user-visible feature and incurring the same level of debt in a core system, I'd much prefer the former... Teams that practice an agile or lean development process are able to minimize the accumulation of technical debt without sacrificing speed, because they work in smaller batches. They also take better advantage of debt, because they find out sooner if a particular investment has paid off... Taking on technical debt does allow investing energy elsewhere, but other new features are not the only option. We can trade technical debt for process improvement, too. If that improvement pays off (by reducing the batch size of our work, for example), it becomes easier to address all technical debt in the future - including the debt just incurred. And because any particular debt might never come due, this is a better trade. To take one concrete example, it's often worthwhile to write test coverage (Unit Test) for legacy code even without taking the time to refactor... We can choose a disciplined approach to making proportional investments in prevention and paying down debt, such as Five Whys... When I talk and write about the advanced product development process at IMVU today, like the cluster immune system or the disciplined approach we take to split-testing and interaction design, it may sound as if we had that capability from the start. Nothing could be further from the truth... n the end, what mattered wasn't that we did everything right, but that our fundamental approach was flexible and resilient. At no point did we stop everything and do a ground-up rewrite. Instead, we incrementally improved our process, architecture, and infrastructure, always learning and adjusting.

Aug08 update revisits this in the context of Mitch Kapor's Software Design Manifesto. When it becomes possible to build products "live" with customers, the cycle time changes and design becomes a much more dynamic process. We still struggle to create Firm software that is defect-free, and it still requires customer insight (and maybe some customer development) to discover what will Delight. But it's Commodity that has become the most unstable. Every time we execute a product pivot - changing some elements of our vision but not others - we change the very purpose of the product being designed. My belief is that it's this increase in the rate of change that is what is causing our technical design intuitions to go haywire.

Related: some discussion over whether buying/selling Option Contract-s is a better Metaphor.