The death of 1000 cuts - the code base that has had corners cut 1000 times, each time getting progressively worse and worse, until it's so fragile, that even tiny modifications have drastic and unpredictable outcomes.

Global state being modified by race conditions. Over abstractions doing nothing but piling on the call stack. Interfaces ill defined and so there's lots of type casting and copying. Shudder

The worst kind of tech debt is test debt: the huge body of unidentified and undiscussed tests that never get considered. On an "agile" team where there are no test specialists, and the emphasis is on CI/CD with fully automated tests, those tests are confirmational: these tests verify that the code works as expected, and they have to run fast. If you have an SDET, then their work is most likely focused on tooling to improve the efficiency of the dev team, and not to exploring and learning about the applications to drive quality. This is delivering "working code" with eyes closed and fingers crossed, and this test debt hangs like the Sword of Damocles above your company's customers.

The role of test specialists is to try and make the unknown unknowns a little less unknown. If you have decided that it's finally time to hire a test specialist, then you have that huge test debt PLUS immediate pressure to focus on new features.

- https://docs.sonarqube.org/plugins/servlet/mobile?contentId=...

The worst tech debt is whatever is making the current quality leaks worse, generally whatever is being changed or added right now, usually in a hurry because someone shortsightedly thinks it’s business-critical to prioritize speed of delivery above quality standards.

Maybe they are right, maybe they are wrong, but either way whatever they are asking you to break in order to get it done sooner, that is the worst thing going on.

The more effort you spend focusing on making that process leak proof, the less future puddle there will be, leaving time to clean up the existing puddle.

No matter what tech debt there is in older, not-currently-changing-due-to-project-needs code, it is like the puddle, maybe a large puddle, but it is not the leak.

Tech debt created from old business decisions.

You want to know why we added the isPancake method? You'll have to ask Lucy who's back from holiday in two weeks, who mentioned talking to Greg the intern from last summer, who said his old manager Anna said it's very important.

Please don't modify it until you've done that.

undefined

Agree with the tests tech debt comment. Another huge problem is organizing deployments and environment configs in general for those shops not using something like k8s etc.

The kind that keeps growing. Any mess can be cleaned up given time and effort, but if more mess is produced faster than it can be cleaned up, it's a lost cause.

Overengineering. You can always refine chaotic code, but cutting down and simplifying abstract code can be almost impossible.

Long workflows.