That was a frustrating video to watch. There are a few obvious flaws, like the “proof” that doesn’t actually prove the original claim at all, and the way you literally can’t reach the equivalent of

    add x y = x + y

using the proposed Agile programming model. However, the giant elephant in the room seemed to be that all of those tests the presenter was talking about, and any aspects of the overall design of the production code that exist only to support those tests, are themselves what he terms accidental complication. By his own argument, it seems we should never write tests!

This is why I prefer to talk about minimising accidental complexity rather than eliminating it. Essential complexity is logic you can’t avoid. It’s fundamental to the problem you’re solving, and any correct and complete solution must take it into account. Accidental complexity is logic that in principle you can avoid. However, sometimes you don’t want to: diagnostics and test suites bring practical benefits other than directly solving the original problem, and we will usually accept some extra complexity in return for the value they add. Similarly, using a tried and tested tool, albeit one designed to solve a more general problem, may be more attractive than implementing a completely custom solution to our specific problem from scratch, even though again it might introduce extra complexity in some respects.

I don’t really mind whether we break down accidental complexity into finer divisions. There are lots of sources of accidental complexity. There are lots of potential benefits we might receive in return for accepting some degree of accidental complexity. My original point was just that some complexity is avoidable and often it is possible to simplify real world code by eliminating some of that accidental complexity, even if we choose to accept it to a degree for other reasons.