Hacker News Reader

As usual, Brooks has 50 year old insights about this 'novel problem'

> Probably for the same reason that SV companies hiring thousands of developers struggled to improve their product much past the original product, that was built by a handful of people.

Brooks: "Adding manpower to a late software project makes it later."

> Scale in headcount was a tactic to get investment, then you had to find stuff for everyone to work on. Suddenly people have the time to engineer so hard that we get runtime JSON defined CSS rendering engines to produce the same buttons we've had since 1995, instead of just writing a stylesheet and html.

Brooks: "All repairs tend to destroy the structure, to increase the entropy and disorder of the system. Less and less effort is spent on fixing original design flaws; more and more is spent on fixing flaws introduced by earlier fixes. As time passes, the system becomes less and less well-ordered."

> Code output velocity from AI threatens to be useful, except it's also prone to over-engineering and burning tokens on the unnecessary. It's learned from the best after all. My suspicion is there is a lot getting done, but it's just not that impactful to flagship products.

Brooks: "C. S. Lewis has stated it more perceptively: 'That is the key to history. Terrific energy is expended—civilizations are built up—excellent institutions devised; but each time something goes wrong. Some fatal flaw always brings the selfish and cruel people to the top, and then it all slides back into misery and ruin. In fact, the machine conks. It seems to start up all right and runs a few yards, and then it breaks down.'"

That Santayana quote is a bit worn out but applies beautifully here. It's worth recovering its context:

Santayana (1954, p 82): "Progress, far from consisting in change, depends on retentiveness. When change is absolute there remains no being to improve and no direction is set for possible improvement: and when experience is not retained, as among savages, infancy is perpetual. Those who cannot remember the past are condemned to repeat it"

I'm grateful for your framing of the issue from Brooks's perspective. I've been noodling on Conway's law in this changing world.

> organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

With all business functions consulting the central hub of AI to carry out their work designing systems where the users consult that same hub, what system is left except for the central hub?

In that case, what happens to all of Brooks's wonderful insights on how we might work together when we are no longer working together?

Ah yes "How committees invent" is a great paper that I often think about.

The role of software in reproducing organizational designs is a fascinating topic. When organizations adopt ERP, or Office, or buy into the Salesforce ecosystem, or use Jira, they are also adopting organizational designs. I think this plays a similar role to consultancy. By adopting software, organizations are implicitly learning about common practices and internalizing industry knowledge.

As for the adoption of LLM-centered workflows, I suspect that the end goal is not having a great new product that does everything better as is often claimed. I think the end game is making organizations dependent on the vendor. That might backfire depending on how the ecosystem evolves in terms of subscriptions to "frontier" vs open-weight models running locally. I am watching keenly.

I think there is a lot to be said in expanding Conway's analysis, and there is a lot of literature on related topics using terms such as "socio-technical systems" and some other venues in organization science that have a similar approach by other names. I think Giddens' ideas on structuration in sociology could be of interest to you.

Anthropology, archaeology, and ancient history all have some great texts on the development of complexity over time, how it grows and how it collapses and why. In fact the first reference to Giddens' work I read in a fascinating little book about the development of complexity in Ancient Greece via practices of feasting, by Small. Also of course the work of Cline on the Late Bronze Age collapse, and Tainter on social complexity growth and collapse more generally, are fascinating.

I do tend to be fascinated by the study of the distant past but if you look up Giddens you can probably find books and adjacent writers that might help you reflect on Conway's article.

With pay-per-token, there’s also an incentive for over-engineered but functionally harmless architectures. A json based css engine is probably something that can be test-cased really well in the training set.

those thousands of developers aren't working on the FB feed or whatever...

they're working on the ad tech business and other business-related systems involved including internal tools.

and all the other platform engineering shit under the hood that makes much of the web scaleable... and lots of it is open source and contributed to by various engineers from these companies.

end of the day, these are businesses. they're not charities or whatever casual shit.

nobody is stopping you from building a competing product that's lean or whatever.

why don't you do something like that? i'm sure you're a genius.

No seriously, companies hired developers just to starve the competition of talent, raise more investment etc. It was a genuine thing, that left a lot of developers doing pretty meaningless work. A similar thing happens for managers in big orgs, who want bigger headcounts to inflate their power in the org. You get thumb twiddling and initiatives to justify the headcount.

It's probably changing now as VC cash floods into AI instead of web app startups, but I am not talking out of my ass, it's a well known phenomenon.

The industry does not incentivise or reward lean software, the software input for a lot of "software" companies doesn't require it, that's fine. Exactly as you said they're businesses, they do what makes money and go where incentives take them. That cuts both ways, they are not disincentived to have a lot of wasted dev hours, at least not historically.

I think it's more about money and scaling, bus factor is pretty big if run very lean organization eg whatsapp 2014 and that point all those developers are kinda your cofounders and probably start asking much bigger piece of pie. With small teams you kinda trade scaling and availability to velocity. It's much easier to ship but running oncall 24/7 with small team is just nightmare.