Technical debt? Don't spend more than one-quarter of your time dealing with it
Is technical debt -- taking short-term shortcuts at the expense of more stable long-term options -- a bigger problem than it was before 2020? Who knows? It has been around for decades, but impossible to see or measure. It's likely to be more pervasive -- with the recent rush to digital spurred by COVID-19, the overhang from technical debt may be more imposing than it's ever been. A survey released last year by Software AG found 78% of organizations have accrued more technical debt during the pandemic.
Concern about technical debt is rising. While skills issues are still the most pressing issue for executives, technical debt has risen now to become the No. 2 issue, as found in a recent IDG/Foundry survey of 400 IT executives. A majority, 86%, report having been impacted by technical debt in the last 12 months. The survey's authors define "technical debt" as "the measure of the cost of reworking a solution caused by choosing an easy, yet limited, solution." The fallout from technical debt included 43% citing limited ability to innovate, 41% mentioning difficulty meeting SLAs, and 37% reporting outages and downtime.
Also: Building software these days: Design thinking, hybrid teams, and, of course, DevOps
"Technical debt accumulated during the COVID-19 pandemic looks set to shadow CIOs for a number of years," Keri Allan said in a January post at IDG. "In the rush to ensure businesses could keep running, many organizations have been left with ill-fitting or unnecessarily complex technology solutions. Take just one of the 'quick fixes' many businesses undertook; speeding up adoption of SaaS productivity applications such as Zoom, MS Teams, G-Suite, or Office 365. In addition, implementing cloud at short notice also meant not always having time to choose the right type of solution for that service. This can lead to unexpectedly high cloud bills or 'cloud shock.'"
Featured
While it looks as if IT leaders are aware they have this overhang, technical debt isn't so easily detectable. "The problem is that most technical debt is secret -- an unknown and an undefined off-balance-sheet liability," according to Wayne Sadin, technology analyst, quoted in a Cutter Consortium perspective.
So, what's the best way to commit resources to handling technical debt? It would be counterproductive to spend most of one's time attempting to re-engineer systems and solutions plugged into place, as that means no time to work on new initiatives for the business, thus compounding the debt. That's why one seasoned tech industry developer suggests blocking aside no more than 25% of one's time to recasting and rebuilding less-productive solutions.
Also: We now work in an open source world; here's the data
There's another, important twist to this 25% concept, as explained by John DeWyze, staff developer at Shopify. As with all challenges, there are many flavors of technical debt. DeWyze proposes a 25% rule as applied to four levels of debt:
- Daily debt: Devote 10% of time (4 hours weekly) to tidying up code under development at that moment, DeWyze said. "Engineers should be allowed and flat-out encouraged to use up to 4 hours a week if they want to try and improve code in an area they encounter if they feel it would benefit from it."
- Weekly debt (New Cards): This is "the debt that can be solved by adding a card or issue to a sprint," and technologists should spend at least 10% of their time here as well. "One great example would be if we go to implement some new code and find that we have a more efficient or cleaner way of doing it. We could even refactor some adjacent code to use our new code, again simplifying things and improving our internal APIs."
- Monthly or yearly debt: This means reviewing and remediating projects, and developers should devote at least 5 percent of their time here. This is "debt that takes months to pay off," DeWyze said. Yearly debt requires rewrites, the kind of debt "where after lots of conversations, someone concludes a rewrite is the only solution," he explained. "This, in the form of rewrites, should take up 5 percent of developers' time. This is spent between monthly and yearly debt. This amounts to 2-hour long meetings a week somewhere to talk about planning."
Technical debt is a malady we hear a lot about, but few organizations know where to begin to unravel, short of throwing out their current solutions and starting from scratch. Devoting a portion of time to untangling debt -- but not too much -- can at least help keep things on an even keel.