code and test oppose each other

I was reading one of Michael Feathers excellent blog posts on Symbiosis. His writing really resonates with me. As I get older I feel I'm starting to get a handle on thinking about things more dynamically and less statically. Looking back, if I had to pick the one thing that helped me the most on this road I would say its Le Chatelier's Principle, which I paraphrase as "Systems tend to oppose their own proper function". As I recall, Le Chatelier was a chemist and his principle is worded in the context of chemical reactions. The same fundamental "system of opposition" is also described in Walter B. Cannon's classic book The Wisdom of The Body which I first learned about in Jerry Weinberg's book General Principles of Systems Design (p 177). I'd like to try to explain what "systems oppose their own proper function" means using an example from the body. It's called the Glucose Cycle.

If you eat a donut the amount of glucose (sugar) in your blood goes up. If this increase continues unchecked you get hyperglycemia and you die. Fortunately this does not happen because the body is the result of millions of years of destructive testing! Cells in the pancreas detect the glucose increasing and start producing insulin. The liver and muscles detect the insulin increasing and start converting glucose into a stored form (called glycogen). This naturally reduces the amount of glucose and you don't get hyperglycemia.
If the amount of glucose continues decreasing, you get hypoglycemia and you die. Fortunately this does not happen either because other cells in the pancreas detect the glucose decreasing and start producing glucagon. The liver and muscles detect the glucagon increasing and start converting the glycogen back to glucose.

These two effects work in opposition to each other regulating the blood stream glucose.
All this tremendous activity to keep something else constant.
I find it deeply beautiful and deeply paradoxical.

Bradford Keeney writes about this same paradox in his classic book The Aesthetics of Change. An example he uses is evolution. He writes about the battle between a predator and its prey but goes beyond the 'mere' battle for food and territory. He describes a larger cybernetic picture, how the ongoing battle is itself a means or process of generating, maintaining, and stablizing an ecosystem. That evolution is always co-evolution as John Gall said.

This duality suggests that if you want to understand how codebases successfully change you should also understand how codebases successfully stay the same. To quote The Aesthetics of Change again: "Change cannot be found without a roof of stability over its head. Similarly stability will always be rooted to underlying processes of change".

In this light I see test driven development, as much more than simply specifying required behaviour (as important as that is). I see coding and testing working in opposition to each other naturally regulating each other. The ongoing 'battle' between coding and testing, between change and constancy, is itself a primary means of generating, maintaining, and stabilizing the development process.

My instinct tells me good software development is full of processes regulating each other via feedback like this. I'd like to make a collection of them. What's your favourite example? Please tell me. Thanks.

No comments:

Post a Comment