You either have tech debt, or you haven’t done anything.
It’s like cleaning, you’re never done cleaning, you just stop when the dirtiness is at an acceptable level.
Now, if someone said “We have very little tech debt because people who take on our tech debt are promoted or given bonuses.” That would be wonderful.
Cleaning up old tech debt is actually a good job for book smart / business dumb new hires. Its the kind of work that gets you experience working in the environment and learning the landscape of the application, while adding value to the firm straight off the starting block.
And, in theory, the faster you clean up the backlog, the more attractive you become to your seniors when they’re fishing around for support on new projects.
Some people actually enjoy it too. They just don’t do it because adding new features is the thing that bonuses, promotions, etc. focus on.
From my experience in O&G, the thing that delivers bonuses/promotions/etc is making clients happy. A lot of that just comes down to rapid turn around time, low system downtown, and low instance of repeat fixes for known issues.
I’ve been fielding Azure DevOps implementation over the last six months (to date, we’ve just been getting Server/DB Admins to shepherd the files to our systems manually) and getting it right has been a big part of my evaluation for the year.
Tbf, I might have seen a unicorn: A hospital with no tech debt neither me nor my technically more inclined colleagues could find. And we were literally paid for looking for things swept under the rug.
They had a top notch IT department with very professional management who (despite their limited budget) managed to attract talented people - simply with good working conditions, a room for creativity, etc. Everything they had was so well documented that it made me cry and think of my company’s documentation. And while they intentionally did not go with every trend and fad their stuff was rock solid and modern. I have seen much much larger companies with half their thought into infrastructure, etc.
I don’t know if they still maintain that standard,but it was a real unicorn.
That sounds wonderful. Typically if a place has that little tech debt it means that they’ve overhired and there isn’t enough work, but if you said they were on a limited budget, then maybe not. It does sound like the kind of place where I can imagine that happening though. A tech-focused workplace would probably find or create other work. For a hospital, the IT department is a random cost centre, and probably fairly cheap compared to doctors, medical equipment, insurance, etc. And, a hospital probably understands much better than most workplaces about why security is important (keeping patient records private), why a “move fast and break things” attitude is sometimes a terrible fit, why documentation and checklists matter, etc.
Did you ask them if there was any tech debt? Because, I wouldn’t be surprised if they thought there were things they could improve. Like, the documentation probably looked complete to you, but maybe they knew that there were a few areas they could have done better. Like, with the “cleaning” analogy, I’ve been places I thought were spotless, but the people who cleaned it always thought there was more they could do.
Sadly the realities are different: I visit around one healthcare facility every other week in all of Europe, far more infrequently in Africa, Asia and Oceania.
Hospitals consistently have the worst IT departments I ever see - outdated technology, budget constraints (I literally saw a full IT loss due to “we don’t pay for our firewall licences for over 3 years”) and a fucking lack of care. One of the most well known clinical information systems has a hardcoded admin account with a single letter as PW in it Another popular system will try to install an ancient version of TeamViewer. In other words: It’s a mess - btw often the budgets are huge and more than what nurses cost.
That’s why this unicorn stuck with me. They were “relaxed” - because they all had a workload that was “manageable”, there was someone to take over if shit hits the fan,etc. And they didn’t feel like they would need to do this and this - I know and fear this myself, it’s the bane of my existence as a project guy. They? They had a nice, lean but powerful project workflow and change management.
In the end it all came down to very very good management - a manager who knows their team that well is worth their weight iin gold.
Probably good support for that manager from the levels higher up too. Because, like you said, that sounds like a unicorn. That sort of thing just doesn’t happen.
I’m filing this away for some future argument. Thank you.
Any time I have a “superior” that insists tech debt isn’t a problem, I feel an incredibly strong compulsion to lock them in a room with a laptop and tell them to implement something extensibly and maintainably in our codebase, and that they won’t be let out or fed until they do.
And by “implement” I mean write the code and the tests and test automation.
And then they have to pass a code review, and write appropriate doc for any externally facing interfaces/apis/ui/etc.
We’d stop having stupid fucking opinions like that right goddamn quick if this policy were implemented.
What are tests and test automation? What documentation? What’s a code review? Can you please come talk to my boss?
Your boss doesn’t get to leave the room, it seems.
Yeah I’m looking for a new job but I have to develop skills people want now.
You know there are object oriented languages? Well, try three different retired programmers who made attempts to implement objects three different ways into C.
It’s great!
Oh, it gets better: three different retired programmers who made attempts to implement objects three different ways into C, in the style of three entirely separate languages that are idiomatically alien to C.
Are you a previous hire at my company? You sound like you should be a manager here with those great ideas
The last person that startet in our department and decided to go while they still can said “you can only stack shit that high…” and i think its beatifull… imagine a codebast that startet in assembly bad c code with lots of hardware specific shit and the demand to always ship features to old systems build byy electrical engineers who didnt know better.
I hope in like 10 years i will understand how all of the stacked shit works…
Our tech debt could buy Twitter, sorry, X.
Our tech debt could buy EA from the Saudis.
Our tech debt could buy Apple outright.
Send help
Find a way to borrow against or short your technical debt and buy a small country.
the only way you don’t have technical debt is if you haven’t started the project yet.
And even then, I might have caused a little bit of debt, already…
I interviewed once for an IT manager role at MIT’s Whitehead Institute and I shit you not the hiring manager actually said the documentation for absolutely everything in their environment was perfect, and that everyone on the team documented things very well.
Almost everybody who works there in IT has decades of seniority. I’ve never met a lifer who was great at documentation, let alone an entire team. Pretty sure the guy was just fulfilling some quota of external interviews so they could promote whatever guy was to get the role internally.
Broadly speaking, technical debt is a trade-off between quality and expediency. The problem isn’t that it exists. The problem is that businesses will saddle themselves with debt and refuse to pay it back.
The difference between swiping a credit card and closing the balance out at the end of the month. And carrying around a forever-rising balance on a card that’s charging you 29% APY.
Exactly this. I like to say “the interest on the technical debt always comes due.” The problem isn’t so much that it exists but that organizations fail to manage it. Just like fiscal debt, sometimes technical debt is necessary or advantageous. The key is investing enough effort to keep the balance and interest rate low.
When that doesn’t happen, features take longer and longer to implement as even small changes require increasingly large amounts of refactoring.
Additionally, defect rates tend to rise. In my experience, organizations that don’t like to manage technical debt also don’t like to invest time in proper unit testing.
I used to try to explain to management that some debt is high interest.
It’s true, they’re hiring you to start the project.
Unfortunately not.
I don’t understand why people treat it like a dirty word. Tech dept should be a deliberate choice. it’s not only okay to cut corners to meet deadlines but it’s literally your job to decide what can be cut to meet the business needs
Not everything needs to be done today
My company has started using a survival metaphor of air/water/food.
- Air - “keep the lights on” work; things that will fundamentally stop the product or business (legal, compliance, security) if not done in the next year
- Water - foundational work; tech debt is here
- Food - strategic work, new features, experimentation
It works because it recognizes that you need all three to survive and you have different time scales on which you can survive without them.
We will choose not to drink water sometimes to make sure we can eat some food. But we will die if we only consume food.
I’m on the product side and trying to buy my teams as much capacity to pay off some of our wayyyy overdue tech debt, and this metaphor has made it easier to convey where we are to my higher ups.
That’s a great analogy, I’m going to try to use it at my place, next time I need to explain tech debt
The ultimate red flag. They probably lie about paying you, too.
The boss probably isn’t lying about no technical debt. He’s probably just too dumb or ignorant to know about it.
If he mentions it, one has to assume that he knows enough about it to lie.
He can know about it as a concept without really understanding it and if he he treats the dev team as a code producing machine then he could be ignorant of how much technical debt there is. Or maybe there’s an asshat on the dev team telling him there’s no technical debt.
From now on we will refer to “technical debt” as prepaid capacity.
