A meta-analysis of three different notions of software complexity
15 points by ztellman
15 points by ztellman
I often think that discussions of complexity completely ignore the inherent complexity of the system being modeled. Payroll, actuarial, an air traffic control systems, or your niche line-of-business systems are inherently complex. The resultant software written to model them is inevitably complex as a result. This is exacerbated by them being typically “external domains” where expertise is outside of the software development team.
(Author here) Coincidentally, I’ve been meaning to write about this! :D
There is a particularly complex expense approval flow I’ve been discussing with someone, and it’s equally fascinating and horrifying how the seemingly “simple” task of approving expenses gets hairy so quickly once you start factoring in various real-world constraints.
Yeah, I was hoping the article would cover Out of the Tarpit, which has a really useful discussion of the difference between accidental complexity vs essential complexity.
I feel like Ousterhaut’s definition is the least useful because “why is it hard to modify? well, because it’s complex” becomes a meaningless tautology. It tells you nothing about why.
My reading is that Ousterhout’s real definition of complexity is “the quality that is reduced by following the rules/heuristics in A Philosophy of Software Design.” He wrote the book because he had extracted some useful guidelines from years of teaching undergrads. The attempts at formalization are clearly post hoc.
I think that’s because these talks about complexity are really talking about incidental complexity: the complexity that you necessarily add in the course of solving a problem. Of course you want it to be near zero so that you’re only modeling the complexity of the actual problem you’re trying to solve.
In other words, if you’re stuck modeling something actually complex then there is no engineering you can do that will make that magically go away.
It’s kind of a shame because Hickey’s particular idea of simplicity only really foists complexity elsewhere and makes programming in clojure more complicated than it could have been.
I’ve had the idea brewing for a while and haven’t really seen it elsewhere, but I think consistency is the subsuming concept over simplicity and complexity. If everything works more or less the same, it doesn’t really matter how many dependencies there are, or how dirt-basic the interface is; if you can transfer your understanding over more of the system then it’s less complex. I mentioned this on some other thread but I think this is the reason forth, lisp, and smalltalk can go from 0 to OS: because they’re so consistent.