3 ms·

Inversely I have had experiences with maintenance coders going like mercenaries into code i wrote and without respect for architecture or future extensions mak

by bartwe 15y ago

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.

Flow 15y ago
I've been afraid of this too. 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.
gruseom 15y ago
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,+Musashi%22 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.

by bartwe 15y ago

Flow 15y ago

I've been afraid of this too. 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.

gruseom 15y ago

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,+Musashi%22 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.