←back to thread

116 points benterix | 4 comments | | HN request time: 0.201s | source
1. smokel ◴[] No.45162071[source]
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.

replies(3): >>45162226 #>>45164629 #>>45165341 #
2. ChrisMarshallNY ◴[] No.45162226[source]
Reminds me of this comic: https://www.monkeyuser.com/2018/implementation/
3. monkeyelite ◴[] No.45164629[source]
This is a general trend in society and it is psychologically stressful as issues affecting you shift outside of your circle of control or even influence.
4. gf000 ◴[] No.45165341[source]
> this means that accidental complexity has not disappeared, it has only moved

I would argue that it is essential complexity that we reuse (what the library does), at the added cost of some accidental complexity from dependency management, etc.

Which is a fair price where the essential complexity reuse is larger than the overhead (e.g. it generally makes no sense to bring in isOdd as a separate library, but for larger functionality you are likely better off doing so).