alt Hacker NewsIf there's a leaky, tangled messy piece of incredibly complex software, but it's small and enables lots of other pieces to be simpler, then it's great.
That's where typical ideas about complexity fail (selecting scope). It's easy to point out a specific part of the code and say it is complicated, without realizing it enables other parts to be simpler.
I've seen a fair share of refactorings that ended up simplifying a core logic but making whole sections that depend on it worse.
Replies
In his "Power of Simplicity"[1] talk, Alan Kay had a great illustration of this specific phenomenon using astronomy:
Before Johannes Kepler had the insight of describing the orbits of the planets with ellipsis, peoples were using the (conceptually simpler) circles which didn't completely match the observed movement of celestial body such as Mars, thus resulted in complicated circle-within-circles orbits to try to model reality. By introducing a more complex basic shape (ellipsis instead of circle) which happened to match the underlying reality more, the overall description of orbits got greatly simplified.
It's a phenomenon I've seen a few time in my career so far: that while often there's complex code because there are actually complex hedge case to handle (essential complexity), sometime it's really because the data structure used to model the thing you're handling is slightly missing the mark, making things fit almost-but-not-quite, and many operation done around to handle data can be greatly simplified (if not avoided altogether) by changing the underlying data-structure.
(Also, Alan Kay apparently did another talk called "Is it really complex, or did we just make it complicated"[2] that seems pertinent to the thread, though I haven't watch it yet)
[1] https://www.youtube.com/watch?v=NdSD07U5uBs [2] https://www.youtube.com/watch?v=ubaX1Smg6pY
I completely agree. I don’t think it’s bad for code to be complex if it’s essential complexity that has to go somewhere. To me it’s a red flag when someone cares more about making the code look simple than solving the problem.
I guess what I mean is that you can’t just assume that you can get clever to work if it doesn’t capture some inherent quality of the problem or relies on unrealistic assumptions. In other words, you often can’t just define the abstraction and requirements and iterate/vibes your way from there. Things like the CAP theorem of the discrete number cells in a small blood sample make certain abstractions literally impossible to deliver.