Eternal vigilance is the price of quality
It doesn’t take much to make code stink. One misidentified variable can lead to a train of thought that completely goes in the wrong direction. You may be able to take care of your beautifully designed and meticulously crafted system while you’re the principal engineer on it, but eventually you’ll stop working on it. You’ll find another job, you’ll be promoted to management, you’ll be assigned a new project, and someone else will come and mess it up.
How do you stop the creeping grind of entropy? How do you avoid the inevitable chaos that seems to strikes all codebases as one errant variable leads to mistaken logic which leads to quick patches which leads to dirty hacks and fixes? How do you ensure the system your team built survives without you?
You really can’t. All systems suffer from an eventual decline to ugliness. No matter what design patterns you implement, what laborious tasks you automate, or what documentation you write, eventually someone is going to not care. They’re going to make that first quick fix to your codebase. They will cast that first stone and they’re going to break a window.
The Broken Window Theory comes from the observation that if a window of an abandoned car was broken, the rest of the car was damaged soon after. If the window wasn’t broken, the car remained undamaged. Essentially, the theory proposed that decay occurs much faster if there is a sense of abandonment or there is a visible lack of standards and up-keeping.
This applies to software systems, too. If engineers see that the code isn’t cared for, their default mode of behavior isn’t to improve it — why should they? They can do their job much faster if they don’t care about quality. They’re paid to complete their own features, not fix others’ mistakes, aren’t they? Refactoring might be your first thought (especially if you’re reading programming articles on the internet), but it certainly isn’t the first thought of most developers. If they see crappy code, they’re going to pile right on top of it to get the job done.
You can’t rely on the next developer to keep your system clean. The only thing you can do to ensure quality is to not tolerate broken windows while you’re on the project. Shut down the chaos as soon as you see it. Fix things and keep them pristine. Push back the chaos for as long as possible. Your team will likely start helping if they see you care about the project.
Ultimately, when you leave the project, it’ll be up to whoever is working on it next to have the same mindset. If you’re lucky, it’s a member of your team who understands the value of making time for quality. If not, you at least tried your best and left things better than you found them — that’s all you can do in the end.