Why Technical Debt Matters for Product People
As the person in charge of the product, you may not be terribly concerned about how clean and well-structured the code is. But the quality of your product matters: It directly impacts your ability to achieve strategic product goals and make your products successful: Technical debt makes it hard to experiment with new ideas, release new features, and quickly respond to user feedback. [1]
The messier the code and the less modular the architecture is, the longer it takes and the more expensive it is to change your product. In the worst case, you have to go through a rewriting exercise where some parts or even the entire product are being redeveloped. This is similar to financial debt: When the debt is not paid back, the interest payments can multiply and eventually cripple the business.
Technical Debt and Your Product
To understand if and to what extent your product is affected by technical debt, talk to the development team, for example, in the next sprint retrospective. I find that development team members usually have a good understanding where issues in the architecture and code are.
Additionally, consider asking the team to collect data that shows how much technical debt there is, where it is located, and how bad it is, for example, by using code complexity, dependencies, duplication, and test coverage as indicators. There are a number of code analysis tools available that collect the appropriate data and show how adaptable the architecture and how clean the code is. [2]
Once you understand the amount and severity of tech debt in your product, analyse its impact on meeting the product goals and achieving product success together with the development team. Take into account the cost of delay, the cost of not addressing the technical debt now but delaying it to a future point in time. Should you, for example, continue adding new features to the product for the next six months and plan in bigger technical improvement work afterwards? Or would it be better to address the worst debt now?
Furthermore, consider the life cycle stage of your product. Technical debt is particularly bad for new and young products: If your product has a closely-coupled architecture with lots of dependencies, if it lacks (automated) tests and documentation, or if it is full of spaghetti code, then experimenting with new ideas and adapting the product to user feedback and new trends will be difficult and time-consuming. Similarly, if you want to extend its product life cycle, you may have to first remove (some of) the technical debt before you can make the necessary changes and add new features or create a variant.
Having said that, it is a valid strategy to launch a minimum viable product (MVP) whose architecture, technology, and code has been intentionally compromised in order to reduce time to market—as long as the quality is good enough to adapt the product to feedback from the early market. But apply this strategy with caution: You will have to spend time addressing the technical debt incurred and putting your product on solid technical foundations. This should be done before reaching product-market fit, as you will otherwise struggle to scale up and keep your product growing.
If, however, your product is in maturity—or even decline—and you do not intend to extend its life cycle but focus on maximising the business benefits it generates, you probably want to do as little debt removal work as possible.
Options for Removing Technical Debt
Once you’ve established how much tech debt there is and how soon it needs to be addressed, you face two choices: You can either make time for a focused effort and dedicate a period of time to removing the debt, or you can carry out the work in parallel to enhancing your product and adding new functionality.
Whenever you face a significant amount of tech debt that constitutes a barrier to innovation, you should opt for a dedicated period to remove it. Apple did this with Mac OS X Snow Leopard, which was released in 2009 after nearly two years of work. While Snow Leopard didn’t provide any new functionality, it created the foundation for future releases by improving performance and reducing the memory footprint of the operating system, for example.
I am not suggesting that you should necessarily spend a year or more refactoring your product, as Apple did. But it can be more effective to make a concentrated effort and invest a few months, or at least a sprint or two, in cleaning up the software, as opposed to doing it in drips and drops across several releases. You intentionally slow down, so to speak, to go faster afterwards.
If a refactoring release is the right approach for you, then your product roadmap should reflect this: It should show a release dedicated to future-proofing the product and making the necessary technical changes.
But if the technical debt is not as significant and does not need to be addressed as urgently, then plan in time for removing some debt in every sprint while continuing to improve the user experience and add or enhance features. You can do this by adding tech debt remedial items to the product backlog. This makes the necessary work visible and allows you to track it across sprints and releases. Make sure, though, that the necessary work is actually carried out and requests for more functionality don’t prevent the removal of technical debt. (My article “Succeeding with Innovation and Maintenance” discusses how you can fix bugs and add new features at the same time.)
Preventing Technical Debt
Intentionally compromising the code quality to get a release out and accepting technical debt is all good and well as long as you actually remove the debt afterwards. Often, however, technical debt is created unintentionally in my experience.
Digital products require ongoing attention to their architecture and code. Otherwise, the product quality will deteriorate, which leads to an increase in technical debt. This is very much like maintaining your bicycle on a regular basis, ideally after every ride. And the more you rely on your bike, the more you should care about it, clean it, and fix or replace faulty parts. The challenge is to make time for the necessary clean-up and maintenance work and view it as part of the bike riding experience, rather than a chore.
The same is true for digital products: Some teams feel so rushed and pressured that they repeatedly cut corners and don’t apply good software craftsmanship practices like evolutionary architecture, test-driven development, pair programming, and continuous integration. But these practices do not only help create an adaptable architecture and clean code base. Used properly, they will speed up development and allow you to release new features and functionality faster, not slower—the latter being a common misconception amongst product people in my experience. The opposite is also true: If development teams don’t apply the right practices and tools, then the software is likely to be brittle, not soft and malleable.
If you want to prevent future technical debt, then give your development team the time to learn, apply, and improve the right development practices. In fact, you should expect that the development team creates product increments with the right quality. A great way to do this is to employ a Definition of Done that states code complexity limits and test coverage targets, and to only accept work results that fulfil this definition.
Notes
[1] Technical debt is a concept originally suggested by Ward Cunningham and nicely explained by Martin Fowler. Thanks to Yves Hanoulle for encouraging me to write about it.
[2] I recommend that you add software quality to your KPIs and routinely track it. Quality is leading indicator: If it is decreasing, then you know that changing the product will become more and more difficult unless you do something about it. Knowing if and how much technical debt is building up helps you be proactive and avoid nasty surprises.
The post Technical Debt and Product Success appeared first on Roman Pichler.
Technical Debt and Product Success posted first on premiumwarezstore.blogspot.com
No comments:
Post a Comment