3 ms·

I work in the public sector in a role where part of what I do is project manage/code review/consult the suppliers that build various solutions for our different

by moksly 6y ago

I work in the public sector in a role where part of what I do is project manage/code review/consult the suppliers that build various solutions for our different areas of business. And you really hit the head on the nail with this one. Almost no company that we’ve worked with do things even remotely similar. Which is all right, if what they are doing works for them and produces stable products at a reasonable price and timeframe, then who really cares how they do it? It does make for some interesting codebase transfers with modern public sector enterprise architecture though. Like when a major system goes from one IBM sized operator to another, because the winning bidder changed hands. But that’s another story, and it really just underlines what you say, because even huge international tech companies don’t remotely agree on practices.

gregjor 6y ago
I think our failure, as a profession, to recognize and accept different ways to solve problems holds us back. Programmers almost always dismiss legacy code and anything they didn't write as crap, even if it works and adds business value. There's always a better language, toolkit, paradigm that the original developers should have used. We're good at pointing at mistakes and speculating on how we could have done it so much better, but not very good at honestly studying and learning from someone else's code. Programmers who carry around the idea that they alone know how to write the first ever perfect piece of software, if only everyone would listen to them, cause more damage than the people cranking out working but imperfect code. The perfect is the enemy of the good, but we never seem to learn that. I see this play out in my own work -- I specialize in legacy and abandoned applications. I'm often told by my customer that several developers looked at the code before me and declared it crap, unmaintainable, have to start over with (fad of the month) language. Yet the code works and has been maintained and enhanced for years or even decades (the opposite of unmaintainable). Ugly, yes. Requiring some commitment and study, yes. But not so terrible that starting over from scratch (which almost never works out as predicted) is a good business proposition. Call it hubris, call it fleecing unsophisticated customers, but this attitude just keeps software development reinventing the flat tire in different languages, to paraphrase Alan Kay.

by moksly 6y ago

gregjor 6y ago

I think our failure, as a profession, to recognize and accept different ways to solve problems holds us back. Programmers almost always dismiss legacy code and anything they didn't write as crap, even if it works and adds business value. There's always a better language, toolkit, paradigm that the original developers should have used. We're good at pointing at mistakes and speculating on how we could have done it so much better, but not very good at honestly studying and learning from someone else's code. Programmers who carry around the idea that they alone know how to write the first ever perfect piece of software, if only everyone would listen to them, cause more damage than the people cranking out working but imperfect code. The perfect is the enemy of the good, but we never seem to learn that. I see this play out in my own work -- I specialize in legacy and abandoned applications. I'm often told by my customer that several developers looked at the code before me and declared it crap, unmaintainable, have to start over with (fad of the month) language. Yet the code works and has been maintained and enhanced for years or even decades (the opposite of unmaintainable). Ugly, yes. Requiring some commitment and study, yes. But not so terrible that starting over from scratch (which almost never works out as predicted) is a good business proposition. Call it hubris, call it fleecing unsophisticated customers, but this attitude just keeps software development reinventing the flat tire in different languages, to paraphrase Alan Kay.