Addressing Technical Debt
Agile is the modern methodology of developing software. The Agile methodology is more popular in startups and small companies than large organizations, although that trend is changing. A sprint represents a time period where a collection of features, taken from a backlog are planned for development. Sprints can be 2 weeks to 30 days. Each company’s mileage may vary.
- Error messages and UI text are not centralized into one file. Instead, they are in-line in the source file and not given proper IDs. This would result in a longer product localization cycle and make it difficult and error prone for a user experience person to enhance messages.
- Each developer writes their own private modules for functionality that should really be common and collected in a library.
- Code is not documented well, making future ownership and maintenance difficult and possibly error prone due to incorrect assumptions.
- Configuration settings are scattered and hard coded instead of residing in a central repository. These could be passwords, paths to files, timeout values etc.
- Security is usually under engineered in MVP level projects and ad-hoc implementations are made as a result.
- Conscious choice to ship a product with a known bug that customers encounter and complain about.
There are more involved examples, but this gives you a picture of technical debt. If you don’t pay it down often, it could eventually foreclose you from advancing your product engineering.
You may have heard of the term “re-factoring”. As features get added, software grows in complexity. At some point, it is cheaper to discard the initial code and re-write it. This is termed re-factoring. You don’t want to be surprised when developers use that term.
In a sprint based methodology and where speed to market is important, what are some best practices? How do you avoid surprises and avoid conflicts further down the road? Here is one approach:-
- In the sprint planning meeting, have the developer identify and add tasks for technical debt, as necessary. This will usually start happening in the 3rd or 4th Asking this question at every sprint planning team shows you care for long term sustainability of the code base, even if your company has money left only for 3 months J
- Add such tasks to the backlog or to current sprint, based on business realities. Most development managers should be fans of addressing technical debt immediately.
- Set aside one regular or mini sprint to address one or more technical debts. If feature development needs to happen, be creative and develop features that are not close to the technical debt area being addressed.
Rinse and repeat the above.
Of course, you don’t want to see a big technical debt reduction task in the final sprint before you launch your product, That’s a recipe for delay and angst.
If you are using an external development team, it is important to add a clause for technical debt clearance in the agreement before final hand off. Any debt clearance work must be followed by robust and comprehensive testing and special attention paid to regressions.
If you have followed best practices for addressing technical debt, kindly share