I can argue with many points made in this article, but there's one assumption at the very core that I think is false: that we know how to do it better.
There have been many ideas in software development floating around in the last couple of decades, from pure functional programming to interactive programming and programming by example. All of these approaches -- and the many others I haven't mentioned -- have explored interesting and possibly promising future directions, but all are yet to demonstrate consistently superior results, across various domains, to the "broken" system we have today.
We are still exploring, and maybe some of the ideas people play with today will serve as the seeds of future, revolutionary development procedures. But it's not like we know today how to do it significantly better even if we wanted to do away with the "old" ways right noe.
I read it more as frustration with the commonly expressed opinion that revolutionary attempts cannot succeed and that only incremental evolution is worth attempting. Not arguing that everything should be revolutionised, just that there is room for attempts and that they should be evaluated on their merits rather than dismissed out of hand.
I suspect a lot of programmers develop a kind of immune response to talk of revolution, simply because it so often comes from people who haven't understood the problem, are not aware of the history or choose to ignore the realities of compatibility and market momentum.
I think that at least part of the problem is this: People find an approach fits them better than all others (of which they are aware). This could be based on their problem space, or personal taste, or both. But they mistake "fits me the best" for "fits programming the best". Then they can't understand why everyone doesn't do it that way. And since they're sure that it's the best way to do all of programming, the only possible explanations for why others don't do it that way is ignorance or incompetence.
Yep, in my experience with my own software, today's "revolutionary, way better designed approach" is tomorrow's "hacky awfulness that needs a revolutionary, way better redesign", ad infinitum. It's much cheaper to accept and incrementally improve an imperfect solution. But I recognize the possibility that this is purely a personal experience and better developers than I really do know "how to do it better".
> better developers than I really do know "how to do it better".
They don't. They're just selling something. Not to say some approaches aren't better than others, it's just the only way to know which approach is really better is to implement the same problem space in both and compare. Anybody telling you that X is better than Y at Z without personally using both X and Y to do Z is just trying to sell you something. Beware.
It's also why the best test when deciding on a programming language or framework is to look at what others have actually created with it.
"It's also why the best test when deciding on a programming language or framework is to look at what others have actually created with it."
To a point. If everyone followed that rule, no one would ever build anything in anything new. At which point, looking at what others have actually created with it would merely be a test of the longevity of the programming language or framework.
There have been many ideas in software development floating around in the last couple of decades, from pure functional programming to interactive programming and programming by example. All of these approaches -- and the many others I haven't mentioned -- have explored interesting and possibly promising future directions, but all are yet to demonstrate consistently superior results, across various domains, to the "broken" system we have today.
We are still exploring, and maybe some of the ideas people play with today will serve as the seeds of future, revolutionary development procedures. But it's not like we know today how to do it significantly better even if we wanted to do away with the "old" ways right noe.