Imaginary problems are the root of bad software

It's hard to admit that your baby is ugly.

They are acting rationally within their belief system of making money.

Enterprise software is exactly that, software used by enterprise -- it doesn't signify any good qualities (far from it) only that it provides a cost-effective software solution to a defined business need.

The issue is when corps get bailed out, overfunded, or have revenue mostly outside of software (e.g. gov't contracts) as it eliminates cost-effective from the equation... so you just end up with buggy messes (code as a cost center).

You'd have to work in the tiny niches where tech is the true product to find good development ...and even then...

I think this started with the old Apache web server. When the www got started, that server did the job so everyone used it. The problem was it didn't scale, so all kinds of cool solutions (load balancers and such) were developed and everyone building something bigger than a personal blog used that stuff. For most the root problem was that Apache had terrible performance. Nginx has solved that now, and we also have faster hardware and networks, so anything less than HN can probably be hosted on an rpi on your home network. OK, I'm exaggerating, but only a little. Bottom line is that scaling is still treated like a big fundamental problem for everyone, but it doesn't need to be.

Those constants represent the markets supported by that app. By the time the app supports even a few dozen markets, every engineer involved will have exercised their stock options and left.

I find the rest of the article to be bizarre. The discussion around retail banking software seems unacceptably incurious and a very likely incorrect diagnosis of the cause of the problems (it basically stoops to an ‘I could do that in a weekend’ level of criticism[1]). It then transitions to a screed about Goldman Sachs which is, as far as I can tell irrelevant (Goldman do very little retail banking; their software development will be quite different to that done for retail banking), and then some description of how the author thinks (all?) large companies are (mis)run. I don’t know if Goldman was meant to be a prototype for this model of company management but it seems like a particularly strange example (in particular, they still will have some remnants from the culture of being a partnership, so they’ll be run somewhat differently from other big investment banks).

I found the second half did not ring true. I’m sure software projects fail at big companies (including retail banks, Goldman Sachs, other investment banks, tech companies, and so on) but I don’t find the reasons given in the article convincing to the extent that I think that section could have been written by someone who had only ever worked at very small companies. But maybe it’s just me and most companies are so obviously terribly wrong in these ways that no one even bothers to write about them and so I only see subtle ways they go wrong like projects dying off due to management acting in bad-faith ways or rewarding people for things that aren’t actually so good for the company or whatever.

If you’re interested in better discourse around certain kinds of bureaucracy, look into moral mazes.

[1] generally ‘I could do that in a weekend’ is code for ‘I could do some minimum thing that doesn’t actually solve whatever the important problems are in a weekend’