There’s a particular kind of almost-strike called “work-to-rule.” It’s when workers in a factory “adhere strictly to all the working rules laid down by their employers, with the deliberate intention of reducing the rate of working.” Doing exactly what they’re told, and nothing else, means production grinds to a halt. Every formal system in life “is parasitic on an informal system.”[2] We count on people to notice problems, to adjust and improvise in small ways.
The perfect example of work-to-rule is: every program ever. The computer always does exactly what it’s told, nothing less or more. This is incredibly hard to get right! Every human endeavor so far, we rely on people with local awareness. Your blueprint may be lovely, but it’s a construction worker who’s going to notice when the materials aren’t quite right and the walls aren’t fitting, and react to it. A person on the manufacturing line will see when the product is out of whack and correct it. They learned what “out of whack” means from someone else. There’s an informal system underneath.
In the program, there is no person on the ground when decisions are made at runtime. All of that awareness, everything that could go wrong and should be noticed, it all must be programmed in up front. That pushes all of the human context up a level: it’s the developers who supply all of it. We need to understand the program’s environment, the business context, the data, everything. Which problems matter? What can we fix, and what should halt the whole operation? What clues can tell it “this is out of whack?” How will our program react to surprise?
This means all the creativity and conscientiousness and context of all the runtimes is crammed into the development at code-time. The team communication, the adjustment, the humanity: maximize this on the development team. Because we need every ounce of this we can get of this going into the code. It’s all we have to lean on.
We’ve seen from the waterfall process what happens when we try to create a program based on a written set of requirements. Create a development process with a bunch of rules and regulations, emphasizing vertical (in the org chart) communication, and what will you get? That program is already work-to-rule. When the people coding it are also working-to-rule, to any degree, then the code is brittle and unresponsive, just like the production output of a plant whose workers are on this almost-strike.
Be careful about the rules we impose on development. Communication YES, knowledge sharing YES. But let the rules be the ones the work itself imposes. Blind adherence to standards, that’s what the computers are for.
—————
[1] http://www.thefreedictionary.com/work-to-rule
[2] Seeing Like a State, James C Scott. Introduction.