part 1 of 3
“To do this the right way we need to _________.” Fill in the blank. This means a couple of things to me as a product manager and reformed programmer, but I will get to that later.
Technical debt, in software development and software product management, is the amount of rework that will be required because someone chose a less than optimal way of doing things. In a number of daily project stand-ups, and in conversation with software engineers, I often hear the warnings of technical debt.
Technical debt is very real. Yet to the business, the choice to add technical debt to one’s product portfolio may be beneficial.
When I bought my house I took out a 30-year mortgage. I took on financial debt to have a better home for my family. It was a valid decision. It achieved my goals at the cost of additional long-term payments.
Technical debt, in the same way, allows business to realize a benefit sooner, rather than later.
Choosing a more expedient architecture, even one that requires re-writing the whole system later may be beneficial to the overall company. It may assist the company to accomplish business goals that include:
- Realizing market share
- Realizing a revenue stream
- Protecting a revenue stream
- Creating a market buzz
- Serving clients now, rather than later
- Preventing clients from choosing a competitor
- Attracting more investors
Choosing technical debt is a valid business decision.
Every time a product and software team create a Minimum Viable Product (MVP) they are incurring technical debt for the purpose of having a viable product that they can use now.
I know of a very innovative company that went out of business after a couple of years. In that time their engineering re-wrote the product twice. They had 3 complete versions! Each subsequent version was to reduce technical debt and to improve features, especially performance and capacity. In that time, prospects came and went. Few deals were landed. Cash flow from clients never materialized because the company wanted to wait for the “next better version.” Overcoming technical debt was paramount and the technologists running the company believed in “doing things the right way” at the expense of running the business.
That company failed. There is only so long that a company can exist on investor money. It was sold for a loss for the investors and staff.
Every time I hear “To do this the right way we need to _________” I immediately wonder if the person understands the business goals and not just the technical aspects of the project. Ultimately good product management is finding the balance between business needs and technical needs.
I’m not afraid of technical debt. You shouldn’t be either. We should strategically use Tech Debt to improve our product’s velocity. Some Tech Debt is good.