This is one of those posts that should've been a tweet. That is if I'm successful in distilling the essence.
Technical debt has a special place in the hearts of software engineers. The privileged ones get to build a business on it, surviving long enough to accrue a lot of them and not fall apart.
Big Tech tend not to talk about it, preferring to act as if they have none. The real deal talk about it with very slight hint of pride, like daredevils performing death-defying feats.
There's a special breed of technical debt I want to highlight. For lack of a better term, I shall call them dirty code.
The juxtaposition to Uncle Bob's clean code is interesting. Clean code is made out of a well-defined set of qualities. The lack of these attributes however does not make a code dirty; they are simply not-clean.
Dirty code belongs in the realm of chaos. It is not compelled to confine itself to any arbitrary definition. However, they are exceedingly easy to spot.
Think of dirty code as low-class technical debt. Wrong placement of files; camel case instead of snake case; bad styling; poor indentation, etc.
What makes code dirty is their overtness. Other kinds of technical debt/coding malpractice are about unintended consequences from illegible design choices.
Not dirty code. They stare at your face; the only condition for you to not spot it is incompetence.
They are low hanging fruits kind of coding malpractice. They are easy to fix, but not easy enough to be automated. Linters sometimes exists to enforce this but not every ecosystem has them; and for those who do I'm sure someone would find it too constraining.
Mostly they don't get fixed early because they appear harmless, and we're too cool to bother with it.
When would dirty code becomes a debt so intense that you reach the development equivalent of Minsky moment? How much is too much?
Here's a suggestion: when it leaks into culture.
Given the condition that new members join the team, not all of them are confident or assertive enough to challenge the old ways. When they have to write something new on top of dirty code (broken windows), they have two choices: subvert it, or conform to it and leave it alone.
The safe and probable choice is to stay consistent. Monkey see monkey do. Now one dirty code leads to two. The cycle repeats, two dirty code leads to four.
Dirty code has now become ingrained in the culture.
Even more significant design trade-offs don't have this kind of broken windows effect.
Top comments (0)