View: Judgment
Our work as software developers involves us in some of the most complex deterministic logical systems that have ever existed. The essence of our job is to find ways of solving problems using abstract mechanisms that can operate without continual human intervention. We find it tempting, therefore, to imagine that there might be an algorithm for software development itself: input requirements, turn the crank, and software comes out. The "Judgment" view helps us see why no such algorithm can exist.
The truth is, no one can tell you exactly how to do your job. If they could, your job would be automated, and it would cease to be yours. The key reason to keep Humans around in a software development system is that they are capable of exercising good judgment in complex, uncertain, high-risk environments.
Judgment goes hand in hand with Autonomy. You're paid to make decisions your managers can't make well—because you have information they don't. Again, there isn't really any way to get around this. If your manager could define exactly how your job should be done, they'd either do it themselves or hire someone to automate it. Thus, the nature of management is to set high-level goals, and let individuals figure out how to satisfy them in context-sensitive ways. Judgment is our term for the act of weighing tradeoffs between Forces and, where possible, finding designs that transcend tradeoffs.
The application of judgment isn't a one-and-done task. It's a continuous process of keeping the system healthy while looking out for the unexpected. Judgment means observing and responding in real time. It's like driving.
Driving is not about getting the car going in the right direction. Driving is about constantly paying attention, making a little correction this way, a little correction that way.
—Kent Beck, Extreme Programming Explained, 2nd ed. p. 11
Richard Cook noted that complex, hazardous systems (hospitals, power plants, transportation systems) rely on the continuous application of judgment to steer them away from disaster.
[A]ll practitioner actions are actually gambles, that is, acts that take place in the face of uncertain outcomes. The degree of uncertainty may change from moment to moment. That practitioner actions are gambles appears clear after accidents; in general, post hoc analysis regards these gambles as poor ones. But the converse: that successful outcomes are also the result of gambles; is not widely appreciated.
[...] Organizations are ambiguous, often intentionally, about the relationship between production targets, efficient use of resources, economy and costs of operations, and acceptable risks of low and high consequence accidents. All ambiguity is resolved by actions of practitioners at the sharp end of the system.
[...] People continuously create safety. Failure free operations are the result of activities of people who work to keep the system within the boundaries of tolerable performance. These activities are, for the most part, part of normal operations and superficially straightforward. But because system operations are never trouble free, human practitioner adaptations to changing conditions actually create safety from moment to moment.
All of this means that good judgment is a key attribute of any software engineer. Judgment is what we do — it is, almost by definition, the part of our work that cannot be automated.
Work-to-Rule
What happens when people stop exercising judgment and just follow rules? This isn't a thought experiment; it's something that actually happens. It's called a work-to-rule strike.
In a work-to-rule strike, workers do only and exactly what they're told. They also make sure to comply with any procedures or rules set by the company, especially if those rules don't make any sense for their context. The result is predictable: productivity grinds to a halt.
Work-to-rule strikes are an effective form of labor action precisely because judgment is the essence of human work, and companies cannot function without it.