The problem that I have with this thesis (that shipping culture is hurting us) is the results people have. You can certainly argue that a better result could be achieved by taking more care with your design, but it is unclear that in doing so you would have achieved something more "valuable" than you did by shipping and iterating.
I do agree with Gary Bernhardt that infrastructure is not getting the attention it deserves, but as we saw with GPG it isn't something that is easily funded. Sun paid an engineer who did mostly nothing but maintain xterm (and the Sun tools equivalent) for several years. Where are you going to find a sponsor for a new terminal? Current terminal code could be improved of course, but in so doing would you get better code? Better systems?
The thing is the "Think carefully and create deliberately" approach has been tried so very few times. But when we have tried it we've gotten Lisp machines, ACID RDBMs, strong typing, and many other important and very useful tools. I'd say it's worth a shot more often.
We know we're in a world of hurt now, but the argument against it is "oww. Devil we don't know!".
The "think carefully and create deliberately" approach has given us a lot more than that - there's also Smalltalk, Xanadu, Eros/E, NextStep, BeOS, microkernels, Plan9, Dylan, and General Magic.
A look at that list is pretty instructive for why more people don't take the "think carefully and create deliberately" approach: by and large, the creators of those projects failed to profit from their inventions. In many cases, they wasted years of their life slaving away in pursuit of perfection, and the market didn't care. If you study any of the systems I mentioned, you'll find some incredibly elegant and beautiful CS concepts, ones I wish I could use for every-day programming all the time. But the problem is that none of these innovations exist in a vacuum, and in the time it took to perfect the product, the market passed them by and the world changed in a way that made them no longer relevant.
"We" and by that I mean software engineers, used to do the 'Think carefully and create deliberately' all the time, we called it software architecture. But "They", and by they I mean software engineers with a 'ship it' culture, got stuff to market faster and improved it faster, and called it 'ship and iterate'.
Lots of people were called out as "old fogeys" or "dinosaurs" when they asked to think through some of the ramifications of shipping things. Those folks got trained that such behavior is a quick way to get managed out of an organization.
It would be interesting if, as an industry, wave 3 (which like wave 2 before it is a decimal order more engineers than its preceding wave) decided to go back to a more mindful way of developing software. And if so they could remain employed amongst the wave 4 cohort.
There's also this really ugly aspect of the ship vs. art spectrum:
ship ------------------------> art ------------>
At the most radical "ship it" end of the spectrum, you get things like nightlies. It's difficult to ship more often; you know when you're shipping a little bit too often because your bug database tells you. There's a real limit there, where you just can't ship it any more often than you already are.
At the "art" end of the spectrum, you can spend months refining a product and never really know if you're done yet. It's completely open-ended. Your bug database will never be empty, there will always be another feature request, and you can easily end up working on version 2.0 when 1.0 never even left testing. You can go forever in the "art" direction.
I agree wholeheartedly with the author's complaint. I spend most of my time interacting with end-users of software and other engineered systems. People are really frustrated. I keep trying to communicate their frustrations to programmers, but programmers keep blowing it off: "oh, people just hate change, they'll get used to it"; "they should update more often, we fixed that bug right after the software was released".
I used to expect there'd be some kind of backlash at some point, but now I think it's worse: a lot of people gave up, they just don't expect trouble-free software anymore. It happened just the other day with a bookkeeper who visited a client's office while I was there: "this will just take a minute ... oh, Quickbooks updated ... oh, huh, it needs me to re-enter all that information I entered a while back ... I'll have to look that up ... oh well."
And it's not just the end-users. Programmers expect software to be broken too. They almost relish it, it seems. "That's just how it is, fix the bug yourself" or "it works for me" are both common responses that completely dismiss complaints from other programmers.
New terminal code could be really awesome. I would love to be able to just drag-and-drop files between terminal windows and have them automagically scp stuff between servers. I'd love to have the ability to open a remote server log file in my local text editor and get everything syntax-highlighted for me -- tailing mail.log with live syntax highlighting in Sublime? Oh yes please.
I do think some infrastructure is getting attention. Containers are (maybe) some progress, AWS has been a huge revolution for a lot of people. But yeah, there also seems to be a lot of popular technology right now that isn't really advancing the state of the art very much, while a lot of nuts-and-bolts parts of the industry are really suffering.
I do agree with Gary Bernhardt that infrastructure is not getting the attention it deserves, but as we saw with GPG it isn't something that is easily funded. Sun paid an engineer who did mostly nothing but maintain xterm (and the Sun tools equivalent) for several years. Where are you going to find a sponsor for a new terminal? Current terminal code could be improved of course, but in so doing would you get better code? Better systems?