To add to this, I think that in the past decades, the rise of large software ecosystems (e.g. around Python, Java, Windows, AWS, Azure), have had both positive and negative effects on accidental complexity.
On the one hand libraries and platforms save developers from reimplementing common functionality. But on the other hand, they introduce new layers of accidental complexity through dependency management, version conflicts, rapid churn, and opaque toolchains.
This means that accidental complexity has not disappeared, it has only moved. Instead of being inside the code we write, it now lives in the ecosystems and tools we must manage. The result is a fragile foundation that often feels risky to depend on.
A classic. I was just getting started, when he wrote that, and that kind of thinking informed a lot of my personal context, throughout my career.
I feel as if a lot of multipliers have happened that he didn't anticipate, but I also feel as if the culture of software engineering has kind of decomposed, since his day.
We seem to be getting a lot of fairly badly-done work out the door, very quickly, these days.
convolvatron · 2h ago
I think we only got to this point because of a near-complete erosion of personal responsibility
- agile and devops both conspire to treat developers as replaceable standins
- we're not even really expected to hang around and see the consequences of our decisions
- on arriving in a new organization, we're presented with a heap of trash we're asked to just sort of keep it running, certainly not to fix it
- 'industry standard best practices' win over a well designed bespoke solution every time, developers are just expected to write a little glue at most
- managers aren't expected to know anything about the domain at all, but to track people to make sure they did what they said they were going to
- speed to feature is the only metric. instability can be papered over with bodies
- we pretty much stopped systemic testing a couple decades ago
so given that we've been on autopilot to a vibe-coding wonderland for quite some time, I guess we shouldn't be surprised that we've reached the promised land.
ChrisMarshallNY · 1h ago
Sadly, I have to agree. I was fortunate to work for a company that absolutely insisted that I take full personal Responsibility and Accountability for my work.
I was there for almost 27 years, so had plenty of time to deal with the consequences of my decisions.
They were insane about Quality, so testing has always been a big part of my work, and still is, though I haven't been at that company for eight years.
AnimalMuppet · 16m ago
> 'industry standard best practices' win over a well designed bespoke solution every time, developers are just expected to write a little glue at most
Sometimes for good reason. "Well designed bespoke solutions" often turn out to be badly designed reinventions of the wheel. Industry standard best practices sometimes prevent problems that you yet know you will run into.
And sometimes they just are massively overdesigned overkill. There is a real art to knowing which is which.
ChrisMarshallNY · 1m ago
> There is a real art to knowing which is which.
Absolutely, but that “art” is really important, and also, fairly rare.
Many folks just jam in any dependency that is a first hit in a search, with more than 50 GH stars.
One “red flag” phrase that I’ve learned is “That’s a solved problem!”. When I hear that, I know I should be skeptical of the prescribed “solution.”
That said, there’s stuff that definitely should be delegated to better-qualified folks. One example, that I was just working on[0], is Webauthn stuff.
On the one hand libraries and platforms save developers from reimplementing common functionality. But on the other hand, they introduce new layers of accidental complexity through dependency management, version conflicts, rapid churn, and opaque toolchains.
This means that accidental complexity has not disappeared, it has only moved. Instead of being inside the code we write, it now lives in the ecosystems and tools we must manage. The result is a fragile foundation that often feels risky to depend on.
No Silver Bullet with Dr. Fred Brooks (2017) [video] - https://news.ycombinator.com/item?id=40233156 - May 2024 (1 comment)
No Silver Bullet (1986) [pdf] - https://news.ycombinator.com/item?id=32423356 - Aug 2022 (43 comments)
No Silver Bullet: Essence and Accidents of Software Engineering (1987) - https://news.ycombinator.com/item?id=25926136 - Jan 2021 (9 comments)
No Silver Bullet (1986) [pdf] - https://news.ycombinator.com/item?id=20818537 - Aug 2019 (85 comments)
No Silver Bullet: Essence and Accidents of Software Engineering (1987) - https://news.ycombinator.com/item?id=15476733 - Oct 2017 (8 comments)
No Silver Bullet (1986) [pdf] - https://news.ycombinator.com/item?id=10306335 - Sept 2015 (34 comments)
No Silver Bullet: Essence and Accidents of Software Engineering (1987) - https://news.ycombinator.com/item?id=3068513 - Oct 2011 (2 comments)
"No Silver Bullet" Revisited - https://news.ycombinator.com/item?id=239323 - July 2008 (6 comments)
--- and also ---
Fred Brooks has died - https://news.ycombinator.com/item?id=33649390 - Nov 2022 (211 comments)
I feel as if a lot of multipliers have happened that he didn't anticipate, but I also feel as if the culture of software engineering has kind of decomposed, since his day.
We seem to be getting a lot of fairly badly-done work out the door, very quickly, these days.
I was there for almost 27 years, so had plenty of time to deal with the consequences of my decisions.
They were insane about Quality, so testing has always been a big part of my work, and still is, though I haven't been at that company for eight years.
Sometimes for good reason. "Well designed bespoke solutions" often turn out to be badly designed reinventions of the wheel. Industry standard best practices sometimes prevent problems that you yet know you will run into.
And sometimes they just are massively overdesigned overkill. There is a real art to knowing which is which.
Absolutely, but that “art” is really important, and also, fairly rare.
Many folks just jam in any dependency that is a first hit in a search, with more than 50 GH stars.
One “red flag” phrase that I’ve learned is “That’s a solved problem!”. When I hear that, I know I should be skeptical of the prescribed “solution.”
That said, there’s stuff that definitely should be delegated to better-qualified folks. One example, that I was just working on[0], is Webauthn stuff.
[0] https://littlegreenviper.com/series/passkeys/
There is a lot of irony in that since the first plank of the agile manifesto is to put individuals in interactions first.
And I noticed you put the development process/structure first over the people who want to treat people as fungible.
https://futureofcoding.org/episodes/062.html