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.

Speed to market is critical when developing software in a startup. Keeping users engaged with new features and improving existing features quickly is a good recipe for successful retention. You have a need to build your product quickly to gain traction to attract investors. Unless you are a successful serial entrepreneur with just an idea. I find that many startups use outsourced development teams to build their MVPs or their first customer facing projects, because they don’t have enough money yet for an in-house engineering team.

If you have to optimize for speed of delivery, you are trading off for well-engineered and maintainable code.  A well-engineered code base is modular, object oriented and extensible. Automated tests, where possible are developed to run tests and the time savings is used to add more code coverage. Unit tests are developed in tandem with developing code. The code is well documented so other developers that get to work on the code in the future can fix issues or enhance it quicker.In the race to develop features and get to market faster, a number of short cuts are taken. Some examples are:-
  1. 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.
  2. Each developer writes their own private modules for functionality that should really be common and collected in a library.
  3. Code is not documented well, making future ownership and maintenance difficult and possibly error prone due to incorrect assumptions.
  4. Configuration settings are scattered and hard coded instead of residing in a central repository. These could be passwords, paths to files, timeout values etc.
  5. Security is usually under engineered in MVP level projects and ad-hoc implementations are made as a result.
  6. 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:-

  1. 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
  2. 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.
  3. 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