Seduction of Reduction

There are many definitions for reductionism but the most fitting here is
…complex systems can be completely understood in terms of their components
…the analysis of complex things into simpler constituents

Aaahh… this is the stuff of programmers. Give us any complex problem and we can quickly break it down into simpler consituents and provide a solution. Unfortunately, this habitual mode of thought also stops us from *really* seeing things they way they are.

The problems we deal with are indeed complex, but by no means linear. By this, i mean that the impact on the global system of a proposed solution in one area cannot always be accurately predicted. This becomes particularly true as the scope of the system increases. Manifested, we look to the codebase to see how this principle plays itself out.

As the codebase grows, small changes may ripple across the system and produce undesired consequences somewhere else. This is not always a design flaw, but can be attributed to the natural evolution of the system. However, in both cases, you end up with the same emergent non-linear complexity. Wether it falls into complete chaos or not is another discussion 🙂

Our linear reductionism works effectively in small systems where the number of interacting components is easy to snapshot at any one time. As it grows, we need to adapt our thinking to facilitate this shift in complexity. This pattern of thinking i call, Density Dependance, adapted from a similar concept in the research of AI.[1]

When we start finding that our habitual reductionism starts letting us down [manifested most notably by statements like: “Aaah.. yes, i forgot about that”], we should flag ourselves to start actively looking at the global properties of the system and start thinking about solutions “holistically” [ although i’m quite hostile towards that word itself 🙂 ]. How we think directly depends on the density of the solution, and conversely, the density of the solution depends on how we think.

Ironically, loose coupling contributes towards complexity through perpetuating the fallacy of composition, yet, it’s [LC] considered a good practice.
If all my components are reusable, i should be able to plug ‘n play different components- thereby making TheSystem itself a reusbale component.
Integration is easy? Not that loose coupling is a bad idea. It’s just funny, is all 🙂

Even more funny, when business employ reductionism to negotiate deliverables, dev reacts badly:
If it takes one developer 4 days to do the job, then it should take 4 developers one day. So why can’t we ship on Tuesday?
Again, we’re never really engaging with any kind of linearity, so that kind of maths won’t fit. And software delivery is complex [on many fronts] but governed by a few deeply simple rules in order to manage the complexity. Get your simple rules right, and it’s B-E-A-Utiful 🙂

And again, the theme keeps coming up time and again– even they way we think about our project should just be one of many tools we have available to deliver successfully what we, as programmers, agree to deliver.

References:
[1] Brooks, R, Cambrian Intelligence, MIT Press, 1999