Shipping Culture Is Hurting Us

It's not even a good rant. Author is fundamentally wrong in their choice of examples and targets.

Every time I see someone quote that JavaScript was designed in ten days I cringe.

JavaScript was designed in 1995. It was standardized as ECMAScript in 1997. Ever since then, it's been under active development by a thriving community of engineers pushing for better standards.

It's been a bit longer than ten days.

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 forgot what my point was supposed to be.

All things in moderation..

To me, "ship it" as a philosophy means the most important thing we do as developers is deliver working code to customers.

On my team, when we encounter a concept that is just too complicated to ship right away, we try to branch-by-abstraction and keep shipping changes, even if the feature isn't "ready" yet.

To me, the marginal returns on trying to be right diminish more rapidly than the returns on making it easy to fix to stuff when I'm wrong. Maybe I'm just not as smart as everyone else here, but it seems to work.

Given that the ECMAScript community has (for good reason; "don't break the web") decided to avoid backwards-incompatible changes, that necessarily places a limit on the amount of "fixing" they can do to the language. New or enhanced features are okay, rectifying mistakes is harder.

(This isn't just a JS thing; go talk to any random Python developer and ask them what they think of Python 2 vs 3. There are tradeoffs to both approaches.)

http://www.2ality.com/2014/12/one-javascript.html