If you manage a website and have found yourself asking “why does it take so long to develop features?” or “why are there so many bugs when we release updates?” technical debt could be the answer.
What is Technical Debt?
Technical debt is the cost of additional work caused by choosing an easy solution now, over a better solution which takes longer. Much like credit card debt, technical debt compounds over time, adding to the ongoing cost of a project.
Technical debt can be accumulated deliberately or inadvertently and falls into one of four categories:
Taking on a level of technical debt is unavoidable and in some cases, it’s the right thing to do. A new product may accumulate a large amount of technical debt early on, in order to get the initial concept to market quickly and gain first-to-market advantage. However - if left unchecked technical debt will compound and have undesired consequences.
Why it Matters
When left unmanaged, technical debt slows down feature development, increases bugs, and impacts your bottom line. A feature that should take a few days to develop, could end up taking weeks or even months to complete, on a project with high technical debt.
Cost of Change
Time is money. The longer a feature takes to develop, or a bug takes to squash, the more money it costs. By actively managing technical debt, teams can significantly reduce ongoing project costs, and make life better for themselves and end-users.
A useful analogy to help understand the relationship between technical debt and the cost of change is household chores. It’s tempting to not bother doing the dishes, vacuuming, or taking out the rubbish. After all - the less time we spend on chores the more time there is to party! That’s great for the short term, but after a while, the dishes stack up, and you’ve got a huge cleanup job on your hands.
In extreme cases, the cost of change can exceed the cost of starting from scratch. That’s a place nobody wants to be in.
How to Manage Technical Debt
As time goes by - projects naturally become more complex. New features are added and existing features become richer. If technical debt is managed, the cost of change will increase slowly, in line with complexity.
There are three key steps to achieving a low cost of change over time: identifying tradeoffs, registering debt, and prioritising repayments.
Step 1: Identify Tradeoffs
Product owners working closely with designers and developers can help identify debt ahead of time.
Imagine your website needs a new event registration feature. As a product owner, you create a user story in the backlog, with some acceptance criteria:
User Story 1: As a user, I can register for an event, so I know a seat will be available when I arrive
- Users must enter their name and email address
- Form submissions are saved in the database
- There is spam protection
- A confirmation email is sent to the user
This feature is released and works really well. Users are signing up for events and the feature is a success. In fact, the feature is so successful, too many people are registering and events now require a waitlist. So you create a new user story in the backlog, with some more acceptance criteria:
User Story 2: As a user, I can go on a waitlist, so I'm notified when space becomes available
- Event coordinators can set a maximum capacity on events
- Users can see how many spaces are available for events
- When users register for a full event they are put on a waitlist
- Users can unregister from events
- Users on the waitlist are emailed when space becomes available
The team gets back to you and says there is a third party solution available which has waitlists, user management, and feedback functionality built-in. Even better, the third-party solution has an API which can be integrated with your site.
Now there’s a tradeoff. You can either build custom waitlist functionality on top of the current event solution, which the team thinks will take a couple of days. Or you can integrate with the third-party solution, which requires refactoring what you currently have, and will take over a week.
As a product owner, you have to decide whether bolt-on custom event functionality or integrate with a third party. There are pros and cons to each approach, which the development team can help you understand.
Building a custom waitlist
Pros:
- You get the feature to market quickly
- You have full control over how the feature works
Cons:
- You incur the ongoing maintenance cost of the feature if there are bugs, or upgrades required
- You only get the waitlist feature, it’s not part of a bigger suite of tools
Third-party integration
Pros:
- Fewer bugs. The feature has existed in the wild for a few years and the kinks have been ironed out.
- Free updates. There is a team of developers working on the third party service. You get the benefit of any improvements they make.
- You get access to a wider set of features, not just waitlists.
Cons:
- Initially, it will take longer to implement and cost more upfront
- You have some but not complete control over the functionality
Right now - the cost of moving to a third-party solution is low. The existing event functionality will have to be refactored, but that’s it. Adding custom waitlist functionality now and integrating with a third party later, increase the cost of change. It will take longer i.e. cost more money to refactor both the event registration and waitlist features at a later date.
You know the feature set offered by the third party will be useful down the track. It will also be harder to integrate once the custom waitlist functionality is built. However - there are event coordinators and users jumping up and down about events being overbooked. So you decide to go for the quick fix, build a custom waitlist, and deal with the consequences later. This is an example of accumulating deliberate and prudent technical debt.
Step 2: Register Debt
Whenever technical debt is identified, it should be recorded in a debt register. A debt register is just a todo list, usually made up of user stories in the backlog. Each item describes a piece of technical debt within the project.
Following on from the event registration example, as a product owner (with the help of the team) you create a new item in the debt register, something like this:
Event Registration
Our current event registration feature is custom-built. To take advantage of a richer feature set and to reduce ongoing maintenance costs, we want to move to a third-party solution.
Risks:
- Historical event data may be lost if not exported before moving to the third party
- If the third party is offline our event registration will be down
Assumptions:
- There is no additional cost for using the third party service
- Users will not see a difference in functionality
Issues:
- Event coordinators cannot currently see how many previous events users have attended
Dependencies:
- Upcoming events are displayed on the homepage
This example is formatted as a RAID log(external link). You can use whatever format best suits your project or team.
It’s important for developers, as well as product owners, to use the debt register. Often product owners are unaware of technical tradeoffs being made by the development team as features are being built. If developers are not adding items to the debt register, raise this with the scrum master, there may be technical debt you’re unaware of.
Step 3: Prioritise Repayments
As part of managing the backlog and prioritising user stories for upcoming sprints, product owners should keep an eye on how many items are in the debt register. When the team starts to feel uncomfortable with the amount of technical debt in the register, items should be sized and brought forward into sprints.
It can be tough to prioritise paying down technical debt over new feature development. But if technical debt is not repaid, features will end up costing more and taking longer to get to customers.
Conclusion
Understanding technical debt and having simple tools to manage it, will help keep your project running on time, and on budget. At Somar Digital we use the agile methodology to run projects while using the Silverstripe CMS to build our websites. As a product owner, you will gain a deeper understanding of project requirements, and be able to effectively communicate with stakeholders about project costs and timelines.
