Yeah, I'm always a bit sceptical of these kinds of articles. Been saying to people for years that everything we build today is tomorrow's legacy.
This whole idealistic fantasy that this time around "we're going to get it right" - whether it's because we're smarter than those who came before, or we have better tooling, or a better framework, or better languages, or whatever specious reason is given - is just that: fantasy.
In the face of changing business and product requirements, and evolving markets and technologies, you have to accept the fact that almost every piece of software you build has a shelf life, and that shelf life is often surprisingly short.
Therefore, rather than try to guess the future (and get it wrong, because most people do, most of the time) you're much better to focus on the problems you have to solve rightnow. Sure, don't code yourself into a corner by building some sort of tightly coupled ball of spaghetti, because that's always going to turn out badly, but to think that's what you're resigning yourself to by focussing only on problems you need to solve rightnow is to conflate two entirely separate issues.
> This whole idealistic fantasy that this time around "we're going to get it right" - whether it's because we're smarter than those who came before, or we have better tooling, or a better framework, or better languages, or whatever specious reason is given - is just that: fantasy.
I'm glad smart people before me have decided that they're going to try and get stuff right or at least more right. Say what you will about Java or C# enterprise software, but I can't imagine COBOL was any more fun.
I'm not against doing things well - far from it - but the idea that you should try to build a perfect system that takes into account every unforeseen eventuality is madness.
Also, agree about COBOL, but software systems these days -
in C#, Java, whatever - are often larger and more complex than those written in COBOL. Partly this is because of higher user and business expectations of what can be achieved with technology, partly it's because the modern tools make it easier (or even realistically possible!) to do that. It's still the same deal though: it's all legacy in the end.
This whole idealistic fantasy that this time around "we're going to get it right" - whether it's because we're smarter than those who came before, or we have better tooling, or a better framework, or better languages, or whatever specious reason is given - is just that: fantasy.
In the face of changing business and product requirements, and evolving markets and technologies, you have to accept the fact that almost every piece of software you build has a shelf life, and that shelf life is often surprisingly short.
Therefore, rather than try to guess the future (and get it wrong, because most people do, most of the time) you're much better to focus on the problems you have to solve right now. Sure, don't code yourself into a corner by building some sort of tightly coupled ball of spaghetti, because that's always going to turn out badly, but to think that's what you're resigning yourself to by focussing only on problems you need to solve right now is to conflate two entirely separate issues.