The history of government's regulation of commerce forms a long repetition of the theme of solving small problems by introducing bigger ones. When lawmakers craft legislation, we may hope that they have diligently considered numerous individual use cases, but they can never take into account all of the circumstances to which their laws will apply. Unintended consequences abound in direct relationship to the scope of the law and the specificity of its requirements. Any broadly-applied prescription for "doing it right" will necessarily be "doing it wrong" to a non-trivial degree in a non-trivial number of cases.
The same principle applies to non-governmental regulators such as standards committees, certifying organizations, and purveyors of so-called "best practices" — though their more thorough understanding of the problem domain may mitigate the effect somewhat. In general, any attempt to provide a rubber-stampable, universally correct solution to any problem necessarily lobotomizes the result of all creativity and initiative. It presumes that situational factors do not apply — or, if it allows for some situational alternatives, it nevertheless presumes these to comprise a known set for which we can prescribe alternate solutions in advance.
The real world is not always so amenable. Thus, slavishly following a standard or regulation often leads to using the wrong tools for the job: processes that target low-priority goals, reporting on matters that apply only trivially or not at all, and changes to procedures that are already in place and working. All of these add unnecessary complexity and therefore waste that most precious of resources: time.
Here are some questions to ask when your client says, "We must implement conformance to the XYZ-123 standard/regulation."
- Must we? Consultant's Cardinal Rule #1: question all assumptions. Consultants often treat imperatives from their client as if they followed the rubbing of a magic lamp: "Your wish is my command, master." All efforts involve a cost, and your client might not stand so firm on compliance if they knew what it would take to accomplish. You should at least consider the trade-off of non-compliance. If it involves somebody going to jail, that's probably too steep. If your client sells software, they might not be able to bear the marketing costs of non-compliance. But if it's just a matter of being able to plaster a particular banner on the website, then the benefits of compliance need to be objectively balanced against its costs.
- What does the letter of the law say? What is the minimum you can do to reasonably claim compliance? I'm often surprised by people who make work for themselves by reading things into the regulations. Even though you may think you know what the authors meant, if it isn't what they said, then don't feel compelled to put words in their mouth. Do the minimum unless you have a good reason to do more.
- What is the spirit of the law? Some regulations and standards are poorly framed. They may include implementation details that have no direct bearing on the result, in order to be "helpful" to implementers. In some cases, you may safely ignore such suggestions in favor of more effective alternatives. Don't slavishly follow the letter of the law.
- Can we turn this to our advantage? This one requires the most thought, but yields the greatest rewards. Each situation will differ, but the general approach is to try to learn something from the paradigm that's implicit in the regulation and apply that learning to your project. The words grok and tao come to mind. Try to imagine a synthesis that harmonizes the two approaches, rather than jury-rigging one to accommodate the other. Be careful to avoid becoming a fanboy, though. Your client needs a solution provider, not an evangelist.
Don't take regulations and standards as absolutes. Like everything else in business, they are merely factors that you must deal with — and potentially tools that might prove useful. They have costs and benefits, and even when they try not to admit it they have options. The wise consultant must take these imposing tablets down from their pedestals, examine them thoroughly, and present the client with all of the reasonable choices that the consultant can discover. Only then can the client make an informed decision about how best to proceed.
Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant blog, he also contributes to [Geeks Are Sexy] Technology News and his two personal blogs, Chip's Quips and Chip's Tips for Developers.