Good Practice, Bad Practice
Trying to maintain and update it has been painful. But at least, I thought, I've got quite a perspective on what not to do when architecting the replacement system, which is what I was originally brought in to do.
Oh, well. The person who brought me in left, the person who I now report to has his own ideas and team, and so -- I see all the exact same mistakes being made developing the new system that made the old one brittle and near-impossible to maintain. How depressing.
But hopefully someone can benefit from what I've learned. The what and why that I'm going to explore here is going to break down into a lot of separate lessons -- and so immediately to #1 in a list of Recipes For Failure:
1. Develop your project with people who don't care.
There are lots of ways to assure this, but a key one is using people who won't ever have to maintain it.
Pay them based on "deliverables" -- once they've handed over "it", whatever "it" is, they get paid and it's Invoice Time. Crappy or non-existent error logging? Not their problem. Inconsistent and uncommented coding styles? Not their problem. Designed to assumptions that don't reflect your development and deployment environments? Not their problem.
Fragile, brittle, difficult to maintain post-launch? Not their problem.
It's so much better if everyone's signed up to the idea from day one that maintainability is each and every developer's "problem".