When you become a Software Manager, the impact tech debt has on your project can only be gradually appreciated. On a day-to-day basis, you're so immersed in it that it's hard to fully fathom. Debt is akin to those lens flares in the new Star Trek movies -- looking straight into it is bewildering, and so you turn away, adjusting the contrast of your visual field to see your current project through to its narrower set of goals.
But it’s still there. All of it, staring you in the face every single day as you fix bugs, work on existing projects, start new projects and plan out future ones.
The pesky lens flare is still there.
“Oh yeah, about that code…”
“We’ve been meaning to get to that… for the last four releases.”
“It was just built like that in a time and place where it made sense, and we needed to move fast to survive.”
As Software Managers, we are constantly crashing up against the rocks of our circumstances. Even if yesterday's circumstances required the code to get out the door asap -- regardless of the cost -- today, that glare is painful. And tomorrow figures to be more of the same.
The short-term fix is sunglasses, but people get to talking if you insist on wearing those sunglasses, indoors, day after day. 😎
linkHow bad is it, honestly?
For years, I struggled to prove to executives why yesteryear's tech debt was so deleterious that it must be prioritized above the new features they wanted to implement today. I would put together spreadsheets, accumulating queries in a cobbled effort to prove that my team was losing percentage points of productivity relative to what would be possible if we could stop and solidify our foundation. The arguments never found their mark. Pitted against the chance to pursue the latest, greatest feature, my hodgepodge of SQL queries and anecdotes were no match.
I would leave these discussions thinking: How can I help them understand? It’s the code -- the code is killing us. Even when it looks great to the user, it’s a coat of paint on top of a rotted foundation. We could realize many of our roadmap's objectives in rapid succession if only we could pause to repair this foundation.
When I started to use GitClear, one of the views I immediately fell in love with was the "Code Activity Breakdown" view. It’s such an approachable trio of graphs that speak to the Provenance, Operation and Code Domain of what is being worked on, it makes my heart weep. This was the view that I wish I could have had at my side when I was arguing about Tech Debt. I wanted to pull up and say, “There! The sluggishness you see when we change any of this code from 6-12 months ago... that is cost we could address directly to accelerate all the upcoming objectives within X system.”
Data from these graphs and the rest of the "Delivery Velocity" page could have let me visually prove to executives the corrosive influence of relying on systems that were rotted at their core. This legacy code that no one wanted to touch -- which usually meant that I would end up having to touch it -- that was the pith of an opportunity to transform our shipping velocity. I would have loved to have this data back then, first to prove how slow we moved when we had to work in the debt-ridden system, and second to show how dramatically our Story Point velocity could leap after we "ate the frog" and refactored the system that had grown derelict from years of abuse.
linkLooking into the Eye of Sauron with Debt Inspector
Digging deeper, the Debt Inspector offers a granular detailing of where the tech debt resides within a project. The detector is trained to call out debt that inhibits current development initiatives, as opposed to detecting latent debt in systems that are no longer used.
Here is what the Debt Inspector can reveal about a three-year window of development on a large-scale Ruby on Rails project that averages about 12m unique visitors per month, serving around 60m monthly page views:
Tech Debt Inspector pinpoints the directories where developer time is being spent, along with approximating how much time is being spent in each directory, so I can relate to an executive "we squandered 40 hours of developer time trying to triage our Ansible config directories this year. Wouldn't you like to have that time back?"
Even when I consult with new clients whose architecture is unfamiliar to me, Tech Debt Inspector paints a rich picture so I can talk to my client in very specific, and thus very actionable, terms. Clients love getting straight down to business when I can detail a list of specific opportunities for them to pursue.
If you’re thinking, “well, I can just pull my tickets, run a query, and add up the hours spent to show where we're struggling,” we are of similar mind. For years, this was precisely the work I undertook to supply my executives with a feel for where their developers' time was going. Thanks to my years following this approach, I became intimately acquainted with its shortcomings:
The most basic problem: developers often neglect to promptly mark a ticket as "started" and "resolved." Any small deviations in when the ticket was marked subtract from the utility of the calculation.
Rarely is a resolved issue a 100% accurate embodiment of what the product team wanted. That is, the ticket's requirements are always shifting in subtle ways, as I discussed in my previous blog, The Drift
The total time spent on a ticket does not decompose into the time that was spent in each of the systems the ticket touched. Thus ticket times don't offer a per-directory prescription of where to reduce debt.
Tickets that touch debt-ridden systems don't only slow down work. More importantly, they destroy developer morale. This can't be measured in "hours to resolve ticket," but it manifests as high developer attrition -- often one of the greatest long-term risks a company faces
linkTake off the sunglasses and ship better code, faster
Before GitClear, most Software Managers, myself included, have relied on a patchwork guesstimation to pick out where the most impactful tech debt resides. The glare from destructive tech debt is blinding, and that made it hard to fully grasp without direct measurement. We know tech debt is there. We feel its sting every time customers email simple requests that can't be accommodated.
Yet we've settled for "best guesses" around how to address the problem. Best guesses don't capture the true impact of what it’s costing your team.