Thoughts? https://twitter.com/cis_female/status/1697763571751674297?s=20

It seems like more evidence that the software crisis never actually ended. We kind of just gave up on solving it. https://en.m.wikipedia.org/wiki/Software_crisis

I take issue with the term "regular" for iOS and Google! They might be extremely widespread, but they don't seem to me in any way typical...

Things naturally cost more if they bring in more revenue. If you help to gradually bring in $100M/yr in revenue, $20M/yr will almost naturally stick to your palms. But that doesn't necessarily compare with efficiencies from an existential war 80 years ago (did the calculation account for inflation?!). In my experience revenues are justification for reduced efficiency. And none of this accounts for the value to society, which is a fraction of the cost if you could somehow (naive, I know) stop trying to think up new ways to juice revenues in user hostile ways. Of course, how do you build just the valuable parts without the hostile parts? You got me.. (This comment partly inspired by the sprawling thread spawned by https://wandering.shop/@cstross/110989030686287315)

The whole idea that a project the size of Google search can be assigned a specific cost misunderstands how large software projects work. Any sufficiently large software project eventually reaches a tipping point where it's too complex to refactor without breaking it. And at that point the complexity and cost of the system spiral out of control. I work on a distributed database product that's built on SQL Server, which reached that point many years ago. Only a handful of people with decades of experience dare to touch the lower levels of the codebase - most of us just glue new pieces on top as best we can. But if a project is lucrative enough, companies will keep shoveling in resources to keep it going. And the SQL org brings in billions, so Microsoft is fine with paying thousands of engineers to work there. At that scale, it doesn't really make sense to talk about the cost of a software project, since it's bounded only by the revenue the product brings in. And that applies even to a project like SQL Server, which is built purely to provide a service and (as far as I know) doesn't include "hostile" features designed to extract additional revenue from users.

@Timothy Johnson I think spiraling complexity is a main part of it, but I don't claim to fully understand it. I believe it can be solved by using smaller teams and technologies that increase individual productivity instead of technologies that try to protect hundreds of programmers from stepping on each other, like Java. I can't prove it, though. I'm very fond of Seymour Cray's response to Thomas Watson Jr. From https://en.m.wikipedia.org/wiki/CDC_6600

The 6600 was three times faster than the previous record-holder, the IBM 7030 Stretch; this alarmed IBM. Then-CEO Thomas Watson Jr. wrote a memo to his employees on August 28, 1963: "Last week, Control Data ... announced the 6600 system. I understand that in the laboratory developing the system there are only 34 people including the janitor. Of these, 14 are engineers and 4 are programmers ... Contrasting this modest effort with our vast development activities, I fail to understand why we have lost our industry leadership position by letting someone else offer the world's most powerful computer." Cray's reply was sardonic: "It seems like Mr. Watson has answered his own question."

@Personal Dynamic Media Yes, there are large coordination costs when too many people are involved in a project. And that applies on the political side at least as much as the technical side - I haven't ever seen an effective decision get made if more than three people are actively involved. But large companies are also wary of trusting any single individual with too much responsibility. They have to be prepared for anyone to jump to a different company at any moment. So just like the software, the organization itself is a distributed system with a high level of redundancy. Startups usually can't afford to have that redundancy, at least in the early stages. I think they just accept a high risk of failure instead. And most of them do fall, but the handful that succeed are more productive by orders of magnitude.

@Timothy Johnson I think the secret there is to take Peter Naur seriously and make sure that at least three people in your organization always have the theory of the program. Once you get down to two or, God forbid, one, you put another person on the team and you make that person do the next five projects, with oversight and advice from the person who has the theory.

The cost estimates are complete fiction, so I can’t really take that Xitter thread seriously.

The very concept of cost makes no sense for something like Google search. Cost is associated with an economic transaction that's small enough for ignoring second-order effects. Google search has economic effects at second order and beyond. It has created whole new sectors of economic activity (Web advertising, search enging optimization, ...) and transformed uncountable other sectors. You can't even factor out something like the "cost of software development", other than by arbitrary rules.

I agree with the comments about how these numbers are difficult to estimate or even define. That said, I think the underlying point of that software development costs are vastly underestimated rings true (in my experience), particularly among developers themselves (myself included). Do others here share that impression? If so, does it suggest any insights on the state of software development tools?

I'd go for the low-hanging fruit: insight about the psychology of programmers, who consistently underestimate the effort to create a useful piece of software, in spite of tons of evidence that includes their personal experience.

Right, could it be that sw tool devs are unlikely to be aware of what takes the most time and therefore would be the most useful to automate? Are they painting bike sheds (with things like flow chart programming, complex type systems, etc) instead of building power plants (with reusable code for common needs, and making sw more modular on higher levels)?