First of all, developing new products is not easy by any means. Sometimes it even seems downright impossible. Along the way, it’s highly likely that a product will accumulate some “technical debt” in its development process. So, let’s talk more about technical debt – what is it and where does it come from?
Ward Cunningham is credited with coining the phrase “technical debt” in 1992 (see one of the first references of technical debt- http://c2.com/doc/oopsla92.html). His basic idea at that time was to create a software product in modules, based on the current understanding of what the product needs to do. The reason for using modularity is that each module could be well-built and understood on its own. That way, if the existing product needs to be changed in the future, it would already be solid and everyone would know how to fix it. Each module would be built correctly, from the beginning. However, the challenge with an incremental approach is that sometimes the whole just doesn’t come together. As a result, modules have to be replaced rather than reworked.
So where does technical debt come from? For one, sometimes you know what the right way to do something is, but it takes too long. So you take an intentional shortcut to get something done quickly. That’s okay if you make sure that you track this technical debt on the backlog (or punchlist) so you can go back and fix it later. Remember that startups are making decisions under conditions of uncertainty and, with limited resources it is simply not feasible to do everything with the product that you would like to. But you can still plan for addressing the technical debt as you move forward.
Sometimes, developers/engineers unfairly get the blame for failing to recognize technical requirements that a founder takes for granted. Maybe the original specifications said “it just has to float.” But secretly, she also wanted it to “go sixty miles an hour.” The engineer crafts a bamboo raft and the founder shows up with an outboard motor. It’s a disconnect about the ultimate purpose. More detailed validation work can help flesh out an agreed upon set of specifications.
And, let’s not forget the “too many cooks in the kitchen” problem. Maybe the first module was done well. But someone comes along later and makes a few changes. Then another person makes a few changes. By the time the fourth, fifth…twentieth person tries to make changes, there are too many bugs. The technical debt has become too big to pay down. The product has to be scrapped and rebuilt.
So, how do you manage technical debt? Like any other debt, recognize that it exists. Get the best people you can afford to build out from the beginning so you start with a quality foundation. If you take any shortcuts, make sure they are intentional and track them to fix in the future. Do the best validation work you can – really live with customers to understand their needs.
You can find more tips for minimizing technical debt in The Titanic Effect. Build strong!