Mindless Process

Coté kindly links to me in this article that pulls together various strands from discussions that have happened in the last few weeks.

Although not quite the same thing, I was thinking about process when he remarked in PodCast 8 that filling out his expense claims was the worst thing about working for RedMonk. It made me wonder whether they had an expense policy and a travel policy and a travel booking process and a travel approval process...

Large companies such as IBM, as you might imagine, do have these sorts of things. A travel policy outlines what kinds of expenses will be reimbursed, what kinds of flights you can take, exceptions, approval processes, ... you get the drift. The problem with these sorts of policies, when drafted sloppily or applied mindlessly, is that they can drive perverse behaviour. Whether a country is "per diem" or "actuals" will determine what kinds of meals you eat and whether you choose to book into a hotel that includes breakfast in the room rate. Bad travel policies will incentivise consultants to "game" the system.... e.g. deliberately choosing perverse routings to trigger a business class flight, etc.

These unintended consequences of overly rigid travel policies are one of the main reasons that large companies have found it useful to explicitly include statements that allow managerial discretion. They are experienced people, whose incentives are correctly aligned to balance the needs of the business with the needs of the consultants.

Exactly the same thing is required for software development: if you mandate a rigid process that applies in all cases and at all times, you remove the need for professional judgment. Adhering to the process will be elevated above the true objectives of the project and you'll descend into process hell. So, like enlightened travel policies, the key to a good development process is ensuring the guiding principles are understood and you allow those with maturity and experience to do what they're paid to do: use their judgment.