|P is for Practical|
Sorry - my box of crayons seems to be missing that colour ;-)
It's a sort of greeny pink :-)
Fault #1: all data was embedded in the code.
Of course that's not necessarily a fault in of itself. It's only a fault if it makes that data hard to change.
That sounds like a lot of dodgy abstractions and duplication of responsibility to me. Time for some merciless refactoring.
As perrin said YANGI is all about avoiding doing stuff until you actually need it - not avoiding it once you need it.
Fault #5: it was shell script fer cryin' out loud. ;-) Seriously - shell script means "no local variables". Everything is always global. Which makes it very dangerous to use new variables as they may already be in use if they are common names, or they're very long if they aren't common names. Ok, that may be a bit exaggerated, but you get the idea. Imagine no "my", "our", or "local" keywords in perl, and then you have the concept.
There you might have me :-) Early architectural decisions like platform and development language are hard ones to change after the fact. If you're stuck with a language with little support for higher level abstraction you're potentially heading for a rewrite.
Of course there are strategies to help avoid this. For example:
At the time it was developed, long before I joined the company, the scope was incredibly small. So they did exactly what was needed at the time, no more. And it worked great. By the time I joined the team, it was already on the verge of bursting. But I didn't know that, so I kept using it.
Sounds like the classic Big Ball Of Mud. My sympathies.
After a couple of years at this, I gained enough experience to be able to see the larger design. (Note how I'm not claiming that it's the perfect design, just larger.) As I said above, the language, which may have been sufficient when we started, was part of the limitations of the existing system (imagine a complex data structure in shell - ewwww!). So a rewrite was necessary anyway.
Yeah, with a shell script you're pretty much stuffed :-)
That's the simplest way to get the long term unknowns accomplished, but not all of my management chain is enthused about paying for "possible future" enhancements when they get in the way of an upcoming shipment, despite the promise that changes required (whether before or after the upcoming shipment) will cost 50% to 300% more than if we spent an extra 10% now.
If you've not come across it already I've found the "Technical Debt" metaphor a really useful tool in helping management understand this sort of thing.