Technical Debt or Technical Fraud
If you are a developer, you surely know that sneaky beast.
It’s capable of drowning the whole business down.
It drains you out of energy and joy.
It makes competent people feel ignorant and ignorant people feel competent.
Its size is measured by the number of WTFs per minute, bugs hopping around on production, lack of focus on your actual work, and the power of the Forest Druid (I will explain).
Meet Technical Debt on steroids — a Technical Fraud.
The nature of debt is that you acquire it in your own name and then you have to pay it off. Due to that, the debt should be a common responsibility of the Developers Team, consciously managed. On the other hand, Technical Fraud is affecting others more than the one who introduced it. And it’s almost never agreed among the team members to take it.
So what is Technical Fraud anyways?
In general, everything you do to the code base, that lets you proceed faster, slowing other people down.
It often happens when someone tries to meet short deadlines or please customers (no matter if they are internal or external). Sometimes it’s associated with something I call the “princess attitude” — leaving tedious work to others and focusing on the most inventory part as you feel like the one who should never waste this precious time on Earth doing whatever could be done by less gifted ones.
Sometimes it’s about believing that your original designs are better than industry standards — you can be right or wrong here, who am I to tell you.
The harm is done when your code is confusing to other team members. It is not a good definition though, since I’ve seen toxic relationships between developers capable of understanding each other’s code, totally cryptic to anyone else. Let me rather put it this way: the code quality can be measured by a speed drop of an experienced newcomer with a proven track of success in other companies.
Actually, I think it would be a great tool to monitor the problem: invite visitors every couple of months and see how quickly they can get on track with your code base.
Red Flags
Is there a development environment in place? Do you need to do manual tweaks to start working with the code (commenting out some lines, running commands missed in the main deployment process)?
Does your code die silently, with green tests and no mention in logs?
How many people do you have to talk to to be able to proceed? How long does it take for them to explain?
How strong is the ownership of a particular piece of code? Do you have to arrange 1:1 with a Developer who works in this company long enough to know how a particular change should be done?
Meet the Forest Druid
I call such a person Forest Druid — someone who keeps all the context in his head, without taking any efforts to share it. His area of domination is cryptic code, likely written by himself.
In the eyes of non-technical people (within and outside of the company) he is respectable as the one who can proceed quickly and stay focused on the main goal.
The thing is that the overall cost of such behavior is high. Unfortunately, it can be easily overseen — it’s spread among all of the other members of the team and maybe it will manifest long after Forest Druid quits his job.
Also, I observed that people doing harm to the code base tend to be more socially skilled than so-called “clean coders”. Maybe it’s about the wiring in human brains.
Or maybe it’s because they don’t give a sh*t and can stay more relaxed during their work day.
If there is a competency gap among the Board Members, the organization is particularly vulnerable to Technical Fraud.
It always happens when management trusts the wrong people.
How ugly is the ugly code?
Imagine that you want to run a bakery. You are not a baker yourself so you need to hire a baker. How can you evaluate your candidates? Well, you can ask them to bake a loaf of bread. If it tastes well — the guy is in.
It’s much more complicated with software development.
Flexible, self-explanatory code actually looks very similar to spaghetti when opened in a text editor. Deep architectural mistakes can be overseen even by a skillful, experienced developer if he doesn’t work with this part of code on a daily basis.
Bad code does exactly the same thing as good code. Until it doesn’t.
Poor quality software exposes the organization to extremely high risks that are almost never measured.
I saw one bug that cost more money than what the company has ever earned.
At the same time, the industry seems to be pretty laid back in that matter. I’ve never seen a programmer hanged on a tree for skipping a unit test.
Don’t get me wrong, I don’t opt for that.
But maybe something should be done about it.
The first step to deal with a problem is to name it, so here is the name.
You’re welcome.
This story was written in cooperation with Maciej Jaśkowski, thank you Maciej!
