"We need to be careful because customers use our software" is a pretty lame excuse. Every company needs to properly test, document, package their software. Some companies do it better than others.

It's not a lame excuse, unfortunately, there is a very real barrier of trust when you talk to a coworker (even from another group) and when you talk to a customer. At the very least, you can agree on a common schedule.

IMHO it's not a coincidence that the blog listed those companies as more "nimble".

Facebook, Google, etc, are somewhat beholden to end users, but not in a way that impedes them from rolling out what they want, when they want to.

Your contact at "big mega corp" that pays for your software may have no ability to change their internal policy that they've stuck with IE6 for years after it was sunset. So, if you want the sale or renewal, you have to support it.

There is a tension here between efficiency and privacy. Inside a corporation with an "open" culture, you can be a lot more transparent and efficient since you don't have the same privacy issues.

Open source projects can sometimes do similar things, for example with the Linux policy of having device drivers in-tree.

Also, Facebook has a history of breaking things for 3rd developers. You can't really do this with enterprise customers who pay a lot of money for your stuff.

We worked around this by having separate release channels, one for our enterprisey customers who opposed all change, and one for our customers who just wanted the coolest things first and were willing to accept some rough edges and lack of documentation.

That doesn't work if _all_ your customers are risk-averse, of course.

The view that people who build and sell products can go faster and have less stress than people who write code for other people is nonsense. The pressures basically are the same; they're just from different groups of people.

I'd argue that almost nobody really knows that. [1] It's just that many developers / companies somehow get away with not being extra careful. How many libraries introduce some "unimportant" backwards incompatible change without bumping their major version number?

[1] ... unless you have a web application and really good statistics. But then, you end up being a large company like GitHub or Amazon, I guess.

When you have a platform for internal use only (or a platform that is available free of charge without any warranties), you can decide to make a change by fiat.

We would like to "move fast and break things", but our customers unfortunately don't appreciate that sentiment.

So developers should develop some kind of taste to distinguish between "real" changes and "cosmetic" changes.

You must be kidding.

Selling into the enterprise space can be very different. There even a single dropped or bogus query can have a big impact on the business. They are paying, so they get to decide if and when they upgrade. You have a small number of very important customers, instead of a billion unimportant customers, so losing one because you didn't meet their bizarre requirement is a big deal, whereas in the consumer space if you decide your app is iOS only, OK, no problem, you can still be successful.

I made updates to some of my code security reasons that ended up speeding things up a little bit (smaller binary to load + less reliance on permanent storage). This caused other developer's code to crash because he inadvertently needed my code to run slow under certain conditions (it wasn't obvious that the issue was a speed thing).

I'm assuming it's usually related to things using multiple threads or at the boundaries of different programs communicating?

It happens quite often when developing concurrent software.

In a non-software company, this is not my experience at all.

While some end-users are local, all communication must route through distorting managerial layers. Huge swaths of features exist from fearful inertia.

Or eventually they do as internally everything starts to rely on everything else and they can't move fast enough when competition arrives.