Imagine with me if you will dear reader, a video call, discussing the scope of a somewhat complex task. There are two paths that can be gone down to meet the deliverable. They both will take the same amount of time, and they will require the same amount of resources. On the surface, they appear to be identically valid. However, one of them would mean doing things “right,” that is, making them scalable, maintainable, and without any additional tech-debt. The other involves cutting corners, significantly reducing the quality, and introducing an absolute fuck-ton of tech-debt (since it will have to be done right eventually).
Which do you choose?
Rationally, you would choose the path that would lead to the solution that allows for easy maintenance and no tech-debt, right?
When asking tech leads and solutions experts why, in practice, the rational solution isn’t selected, instead opting for the “quick-and-dirty” solution, some comments stood out:
“There’s never a guarantee that the “right” solution will take the same amount of time. It’s a safe bet to assume that the quick solution will be 50% shorter, and the “right” one will take twice as long as scheduled.”
“There isn’t a situation where you are not going to incur tech-debt. That’s the nature of software engineering.”
“That’s Agile. The point isn’t to put out a perfect product, it’s iterative. You do what is needed, your “quick-and-dirty” solution, and with each iteration, you improve on it. Tech-debt doesn’t exist, it’s just future iterations or phases.”
When asked how long it takes to get around to handling tech-debt, one developer sent this:
Others had this to say:
“I’ve had to remind our project manager that if we don’t do it the right way now, we’ll never get around to it. It’s just how we work, tech-debt is never revisited.”
“The only time I’ve ever revisited tech-debt, was when a simple update (1 story point, should have been done, tested, and deployed in a day) turned into a months-long fight of untangling poorly written code and tech-debt.”
“Our solutions architect was this dumbass fucking coding bootcamp graduating “full-stack developer” that couldn’t code but felt he was knowledgeable enough to tell other people how to do their fucking jobs. In several instances, we could have achieved the robust solution, that takes care of everything and produces a killer app in a single sprint, or we could do his “quick-and-dirty” solution and it would take us two full sprints (plus more potentially), we always did the quick-and-dirty solution, incurring a ton of tech-debt. His defense was that his fucked solution was “safer.”’
Holy fucking gold-plated frog-shit, salt-bae appetizer eaten in a sewage treatment plant, Batman.
From my perspective, developers see tech-debt as unnecessary (mostly, there were some that pointed out that tech-debt sometimes can’t be avoided), and PMs/POs/stakeholders have a stalkerish secret garden romance with it.
Deadline-Driven Projects Can Get Fucked
My first experience with a deadline-driven project was a lookup tool for a group of agents. There was a single developer working on it. When the hand-off session happened, the developer gave the following estimates: best case scenario: 2 weeks, worst case scenario: 6 weeks. He knew he could probably get it done in 3-4 weeks though, so he said let’s shoot for 4 weeks just to be safe. The head of the solutions team said it had to be done by the end of the week, this was a Tuesday afternoon.
When going through my master’s program, I saw a lot of sites defending the use of deadline-driven projects, ranging from it providing a challenge for the developers (which can create team motivation) to employing Parkinson’s Law (work expands so as to fill the time available for its completion).
The issue with the two extremes is that: one, challenges need to be achievable, and deadline-driven projects do not care about if they are achievable, only that they are achieved, and two, Parkinson’s Law in this case, is total bullshit.
Employing Parkinson’s Law especially pisses me off. You see, it is frequently used as a way to belittle developers, as in, “those damn kids, always taking as much time as they are given… probably on their phones playing Nintendo.” The problem with that attitude is that it mutates time spent from being a measurement of productivity to a target. Let me introduce you to…
Goodhart’s Law
Goodhart’s Law states that “when a measurement becomes a target, it ceases to be a good measure.” Deadline-driven projects take something that is being tracked (a metric that is determining progress, if the project is on schedule, the health of the project, and the performance of individual contributors) and change it to the goal, thereby negating all data collected to determine these metrics.
The analogy I’ve always heard with this law is regarding nails. If your performance measurement is the number of nails created, workers would create thousands of tiny nails, however, if the measurement is the weight of nails created they might create a few large and heavy nails.
By making time the goal, rather than a measurement, PMs incentivize developers to cut corners by potentially sacrificing quality, scalability, maintainability, or functionality.
Agile: You Keep Using That Word, I Do Not Think It Means What You Think It Means
When I saw that multiple PMs responded with comments along the lines of tech-debt being a fundamental part of agile, I was pretty floored. It upset me. I was so mad, I drove the 20 minutes to Ikea, bought myself a nice little table, drove the 20 minutes home, assembled it, and then flipped the fucking thing over.
The general attitude leans towards Agile being something that allows teams to start work with minimal input, that is iterative; a constant process of improvement, and release of features in a controlled cadence, which is why tech-debt is an inevitable evil.
Here’s where that falls apart, like my sanity during my last semester of college. Let's consider scrum ceremonies, something frequently practiced in Agile teams. You sit down with knowledgeable people, stakeholders, scrum masters, developers, and Tina from the third floor that no one knows what she does, but she brings bagels so you let her sit in. You sit down in the sprint planning, you comb through the backlog, you flesh out the user stories, you assign points, you bring things into the sprint, and then decide to do the absolute bare minimum, arguing that we’ll finish it later, just make it work.
Here is your reality check of the day… if you claim that tech-debt is necessary for Agile, you have no idea what the fuck Agile is. Tech-debt is consciously chosen. There are going to be things that aren’t done as part of a sprint, but here’s the differentiating factor: it’s planned to be done in a later phase (keyword planned… fucking planned… goddammit you fucking plan on doing it!). This additional work can come as a result of the process of coding, or it can be a conscious decision to maximize what can be released now, by delaying work by a cycle (fucking delaying). But no, some POs and PMs hide behind Agile as a way to boost their performance metrics. They excitedly boast about the number of points they were able to accomplish in a sprint, ignoring that by sacrificing quality and creating tech-debt, they have effectively doubled the work that needs to be done.
Returning to the “there’s no guarantee” response, if you know that the work is going to take 50% longer if you do it the quick way, why the fuck aren’t you adding that 50% to the estimate? Why are you shorting the time to delivery? If it’s a safe bet that it’ll take a week and a half, then say a week and a half! Shit, say two weeks and do it right the first fucking time! It’s… it’s…
It’s Stupidly Needlessly Pessimistic
The moronic idea that doing something right the first time would take twice as long as doing it the quick way, even if the developers say the contrary (even worse was the time when the right way could be done in a shorter time), is mind-numbingly… moronic!
It’s basically planning to fail. We’re not going to do it the right way, because what if we don’t have time to do it the right way… what if you don’t have time to do it the quick way? That argument that it’s a safe bet that it will take longer is always going to be true. Projects have unknowns, and that always invites the potential for schedule overruns. Taking the quick route doesn’t solve any of those unknowns, it just flat-out ignores them. It assumes that doing the right thing guarantees those unknowns will negatively affect the outcome but doesn’t acknowledge that by doing things quickly, not only are you ignoring the unknowns but introducing new unknowns, in that, you are introducing potential code conflicts that might not surface until much further down the line.
You’re in an Abusive Relationship
Let’s admit it… it’s not that tech-debt is a necessary evil. It’s not that it just happens as a result of the Agile process. It’s not that you are being cautious. You’re in a dead-end abusive relationship, that you feel that you can’t get out of. It’s an obsession. And you need to stop.
I’ve heard stories of catastrophic application failure due to the project team drowning in tech-debt, but the real concern here is that tech-debt actually affects the entire company. It puts the company at risk of losing money due to downtime, slowdowns, bugs, or other critical problems in the applications that provide a foundation for the company's income. Your abusive love affair is actually putting others at risk.
The love affair is also slowing down future projects, not only because of the bugs it introduces but also because it absolutely destroys team morale. In 2021, research was done to determine how tech-debt impacts software engineering (a fantastic breakdown can be found here). The research found that not only does it negatively affect team morale, but it also increases the time spent per week dealing with tech-debt, and slows down ship times.
Tech-debt might be something that has to be dealt with at times, but project managers need to establish a system of dealing with tech-debt, and not actively defending it.
When I worked for dev teams in the US, everything was deadline driven. nothing ever went out on time. The worst part was the amount of tech-debt that we kept accruing. Eventually it took the whole system down, and we couldn't roll back, we just had to fix on the fly. I now live in the UK with my wife, and have yet to see the same batshit insanity from project teams over here. There is a greater understanding that quality is a thing that should be as important as cost and schedule.
Great post