Part 1 of this bite-size series covers whether the terrible codebase you’ve inherited is salvageable, or if it’s in fact a tire fire that only a rewrite can stop.
Before you start code spelunking, take a deep breath and shelve your initial emotional reaction to the codebase. It’s natural to have strong feelings and opinions about something you care about, but they can get in the way of making an objective evaluation. Rewrites can be risky and expensive, so you’ll want to go in with a clear head.
A tire fire can occur using any language, framework, or programming paradigm. It’s bad code that transcends the bike shedding, negativity, paradigm wars, shiny object syndrome, and other emoting common in software development. A tire fire is a codebase with a profound lack of basic programming fundamentals.
There are three signs that occur together in a tire fire. The first is non-deterministic code around every corner. The second is side effects happening anywhere and everywhere. The third is that just about everything knows about, depends on, and affects everything else.
There aren’t discrete units of code, even though it’s deceptively broken out into functions or classes. Most of the state is effectively global and mutable, but without the decency to at least be in the global namespace.
The tire fire cannot be tested. It will not be changed without regular disasters, rollbacks, and behavior akin to replacing the door panel on your car also changing the camber of the wheels and turning the radio into a tennis racket. It is impervious to your attempts at maintenance.
If you’ve determined that you’re the unfortunate party now responsible for putting out a tire fire, come back for part 2 where we discuss uncovering what the requirements for this software actually are.
Leave a Reply