Developers Share Technical Debt Horror Stories (Part 1)
There’s plenty of jokes around technical debt, but what happens when companies leave it to languish? I asked a bunch of developers to share some of their horror stories of technical debt.
Profit Loss
Arthur Linum is a technology consultant. He shared some of his experiences with me:
“I was the consultant for a startup that had accumulated substantial technical debt. They had rushed to meet tight deadlines to position themselves at the forefront of the market, and this had led to code that was quick and dirty.
Unfortunately, their technical debt caught up with them. Their poorly designed code demanded a huge amount of their team’s time and effort to decipher and manage. Simple enhancements would take double the expected time and this caused a slowdown of their production-test-release cycle.
In the end, their extended schedules lost them time on the market causing profit loss.
We had to help them to repay their technical debt by refactoring the entire structure of their code and setting coding standards to ensure no issues arose in the future.”
Arthur Linuma, co-founder and president ISBX
From 50 tickets a day to 1 ticket a week
Channing Norton runs an IT services and security outsourcing firm that helps small businesses in the 25–75 person range handle their IT and their security. As the owner and final point of technical escalation, he effectively serves at the CIO/CISO for all of my clients.
He shared some of his horror stories with me:
“We often begin work in environments that have been neglected or poorly maintained for some time, and, when we do, the elimination of technical debt and the hundreds or thousands of little problems is a top priority for us.
A typical 10 person account will typically be onboarded with us producing anywhere from 3 to 50 new tickets a day, and, after our four-week stabilization program where we wipe out all of that debt, those same clients will average closer to one ticket every few weeks.”
Channing Norton, owner, PC Solutions
The good, bad and ugly
“Based on my experience, customers who use Salesforce CRM accumulate a lot of technical debt in over customizing the platform with custom code. Now the need is always there and sometimes the CRM platform falls short. The solution is the overuse of custom code to the extent that they run out of a lot of issues with further customization, upgrades of the platform which is the very value of a cloud-based tool.
I have seen Salesforce Orgs which are smelly (meaning exceeded the custom code limit and can do no more on the lines of code), ugly (overuse of custom screens which makes it completely obsolete for future point and click changes), and mouldy (use of triggers and apex classes in everything which has made data imports exceed governor limits and horrifying for admins to change even one line for a fear of breaking the whole process and bringing the system down).”
Buyan Thyagarajan, Salesforce MVP specializing in Salesforce CRM and Marketing Automation, Eigenx
Look out for 3rd party integration consequences
“We had a surprise in one of the recent cases where we had a beta feature and came to handle some tech debt around it. While doing it we discovered that the 3rd party we integrated with COMPLETELY changed the public API and integration method, requiring us to handle it first. As developers, we all know these situations where your task is to solve one problem and while trying to do so you discover three more (sometimes more urgent) issues to tackle.”
Aviad Mizrachi, CTO & Co-Founder of Frontegg
Drained Productivity
“Technical debt reduces productivity, resulting in ever-decreasing performance. Code that is poorly written can take more time and effort to decode and maintain. If you ask your team to make a simple code enhancement that would usually take three weeks, you will be shocked to hear that it would take six weeks and may force them to delay other tasks.”
Not only will technical debt delay your team’s build times, but it will also slow your overall production-test-release cycle.
You’ll request new functionality, but these updates will introduce new bugs into the badly written code, making testing much more difficult for your QA team. And, by the time you’ve navigated the code and are ready to release, the team will almost certainly be stressed out from the extended schedule, and you’ll almost certainly have lost profit due to the lost market time.”
Tony Kelly, Founder & CEO at CameraGroove
Overpromise and over compromise
“Many organizations have cultural problems, such as salespeople who sell features that don’t exist, and then there’s a mad scramble to add them. Or someone creates a proof-of-concept demo that somehow winds up in customers’ hands, and now there’s this fragile thing — this thing that doesn’t even qualify as an MVP — that you have to support.
But developers shouldn’t point fingers at other people, because we share some of the blame.
Many of us have worked with someone who didn’t really care if their code was maintainable or their bug count was high, or worse, someone who thought that writing hard-to-understand code would give them job security.
Those are extreme examples, of course, but even the best of us can compromise sometimes; we cave into time pressure and take shortcuts, promising ourselves that we’ll come back later and make our code more robust, but often we never do.
Open source projects can avoid some of this, because (ideally) there are competent people who shepherd the codebase, and (ideally) there is less pressure. But unfortunately, even in open source, technical debt can accumulate.”
Justin Dorfman, Open Source Program Manager at Reblaze
Is technical debt haunting your dreams?
Data is knowledge when it comes to creating a plan to reduce your technical debt. The free Stepsize tool can help your team track and prioritize technical debt based on time lost, team morale, and business impact. It enables you to monitor and identify the existing debt in real-time without workflow disruptions, and you can create your free account now.
