In part one of this series, we established stability as the foundation of any modernization effort. If your system isn’t stable, performance optimizations are essentially meaningless—-after all, a fast crash is still a crash.

We’ve all been there—inheriting a decade-old codebase, with tens of thousands of lines written by developers who have long since moved on. The code works (mostly), but making changes feels like defusing a bomb while blindfolded.

I’ve been working on a new release for a game server I operate on the side and, with any new release, comes opportunities to weep at refactor your older code.

Code is the primary (but not the only) form of documentation. But like any documentation it can be clear or gibberish, programmers need to value clarity and learn how to achieve it.