Jason Gorman has an interesting take on a team’s technical debt being similar to a build-up of lactic acid. That is, if you are in a team that is “unfit” and normally not used to delivering quickly, then running fast, as in sprinting through the initial iterations, will undoubtedly be painful. Much like in athletics, where you can build up “lactic acid” and experience pain and be unable to continue. Jason equates this human sort of feeling to “technical debt” building up in the development project.
While I can appreciate the analogy, avoiding technical debt in a software project is a lot more difficult than becoming more fit and increasing your lactose threshold.
Also, a team can work at a sustainable pace just by coming in at 8:30am, going home at 5pm, not checking emails on the weekend or at night, and plodding through the features and fixing bugs as they come up. Such a “sustainable-paced” team could simultaneously be building up US deficit-sized technical debt (well, okay, nobody could achieve that measure of stupidity
But, I *know* what Jason means. I just think that sustainability is not *the* foundation of Agile. On the contrary, I would surmise that sustainability is a side effect of having a lot of the “right things” going on in your organization, and something to strive for as part of the recipe for success.
“While I can appreciate the analogy, avoiding technical debt in a software project is a lot more difficult than becoming more fit and increasing your lactose threshold.”
If you were to work on avoiding technical debt, how would you start? Root-cause analysis with a fishbone chart? Would that be an effort worth going through here to determine more than the obvious and cathartic reasons? (ie: because my boss/customer is an idiot)
The first step in avoiding a trap is knowing of its existence. Well, if I assume there are traps then I should be prepared at all times. Should we plan on this occurring and be prepared to deal with it?
How do we plan to deal with technical debt and its impact? Is there more than risk management?
Sr Principal Software Engineer