I absolutely agree with this. One of my more flighty cow-orkers sent round this link yesterday - calling maintenance programmers "the residue". Yeah, him and his mates have been talking non stop about how shit systems X, Y and Z are, how they could do so much better etc. Meanwhile, that system, that I maintain is paying all of our salaries. And those boys have produced something approximating... sod all. While getting paid by the revenues generated by that old code.
Inversely I have had experiences with maintenance coders going like mercenaries into code i wrote and without respect for architecture or future extensions making changes because they didn't understand the code and we're not interested in the concepts behind it.
going like mercenaries into code i wrote and without respect for architecture or future extensions making changes because they didn't understand the code and we're not interested in the concepts behind it
This is a problem even when the maintenance programmer is not a mercenary. Check out the essay by Peter Naur (the N in BNF) called "Programming as Theory Building". It's one of the best things ever written about software (albeit in disappointingly bloodless language) and explains this masterfully.
http://alistair.cockburn.us/ASD+book+extract%3A+%22Naur,+Ehn...
The essential point is that source code and documentation, no matter how well-written and extensive, are insufficient for understanding a large system. You have to have the "theory" (the article explains what this means) and for this you have to have someone who knows the theory.
I wrote a system in C# that used immutable data and actually used that to do rollbacks when evaluating a scenario failed. My fears was that since there are no "val" and really bad immutable collections in C#+.Net the maintenance coder would probably remove list.AsReadOnly() and putting in public on setters as part of fixes to bugs.
That didn't happen though, the maintenance guy was really smart and got the ideas without me explaining much more than mentioning immutability.
But this is why languages like Scala are important. Immutability and similar design(patterns) are a result of discipline and sometimes convention in languages like Java and C#. It's bound to fail due to humans being humans.
http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-d...