Tech Debt Cleanup in Phases

By Debanjan Sengupta

Elevator Pitch

An approach taken which will help to cleanup a common tech debt across multiple teams and/or across the product and mitigating any risks while releasing.

Description

Problem Statement

  • We started facing issues with AASM gem, which was at an old version, and the latest version is 5.0.1. We needed to be at the latest version for an important requirement for a module.
  • The AASM gem usage is spread across the application, i.e from Invoicing, Procurement, Suppliers, Expenses, API, Contracts, Payment and many more, where every team has their own priority, sprint planning etc.
  • When we tried to upgrade the gem by simply editing Gemfile, we observed the entire application test suite started to fail, more than 1.5K+ tests failed.
  • We needed a mechanism where individual team can take care of their own module’s AASM. Because a single person does not know each individual model’s detailed know-hows and to fix those.
  • Generally tech-debts has a trend to get pushed to backburners, if there is not a compelling need, in our case, it was a small part of the application, so bringing everyone on the same page about the priority to upgrade was difficult.

Solution

  • We have patched our present version of gem to update the toplevel constant from AASM to AASMLegacy and inherited all the subclasses in the gem from there.
  • Now we have introduced the latest version of the AASM in the Gemfile, which has a toplevel constant AASM. There is no chance of of any conflict now and AASMLegacy and AASM can live together.
  • We created individual tech debt cleanup tickets for all the teams where we are using AASMLegacy, got an approval from the architecture group, conveyed and communicated well beforehand about the approach to all our dev teams to get the idea soaked into everyone.
  • We are planning to continuously upgrade and close individual tickets. Our mission is to update the simple state machines first, where there are less states and callbacks and finally the big pieces which has many states and a complex series of callbacks. Thus giving us enough time to test, analyze risks, performance and security improvements and then release.