Beware the Tool Trap

There has been much written on the role of tools, formal models, modeling, and so on, in software development. Many people claim that UML and model-driven architecture (MDA) are the future, just as many people claimed that RUP and CMM process models were the salvation of the industry.

But as with all silver-bullet scenarios, people soon found out that it just ain’t that easy. Although these tools and models have their place and can be useful in the right environments, none of them has become the hoped-for universal panacea. Worse yet, the misapplication of these approaches has probably done far more damage than good.

Interestingly enough, the nursing profession had similar problems with regard to the use of tools and formal models. They had fallen into the same trap many architects and designers fall for: forgetting that the model is a tool, not a mirror.

The model is a tool, not a mirror.

Rules cannot tell you the most relevant activities to perform in a given situation or the correct path to take. They are at best “training wheels”—helpful to get started but limiting and actively detrimental to performance later.

Dr. Deborah Gordon contributed a chapter to Benner’s book, in which she outlines some of the dangers of overreliance on formal models for the nursing profession. I’ve reinterpreted her sentiments with the particulars of our profession, but even the original version will sound pretty familiar to you.

Confusing the model with reality

A model is not reality, but it’s easy to confuse the two. There’s the old story of the young project manager, where his senior programmer announced she was pregnant and going to deliver during the project, and he protested that this “wasn’t on the project plan.”

Devaluing traits that cannot be formalized

Good problem-solving skills are critical to our jobs, but problem solving is a very hard thing to formalize. For instance, how long can you just sit and think about a problem? Ten minutes? A day? A week?

You can’t put creativity and invention on a time clock, and you can’t prescribe a particular technique or set of techniques. Even though you want these traits on your team, you may find that management will stop valuing them simply because they cannot be formalized.

Legislating behavior that contradicts individual autonomy

You don’t want a bunch of monkeys banging on typewriters to churn out code. You want thinking, responsible developers. Overreliance on formal models will tend to reward herd behavior and devalue individual creativity.^[23]

Alienating experienced practitioners in favor of novices

This is a particularly dangerous side effect. By targeting your methodology to novices, you will create a poor working environment for the experienced team members, and they’ll simply leave your team and/or organization.

Spelling out too much detail

Spelling out the particulars in too much detail can be overwhelming. This leads to a problem called infinite regress: as soon as you make one set of assumptions explicit, you’ve exposed the next level of assumptions that you must now address. And so on, and so on.

Oversimplification of complex situations

Early proponents of the Rational Unified Process (and some recent ones) cling to the notion that all you have to do is “just follow the process.” Some advocates of Extreme Programming insist all you need to do is “just follow these twelve—no wait, maybe thirteen—practices” and everything will work out. Neither camp is correct. Every project, every situation, is more complex than that. Any time someone starts a sentence with “All you need to do is…” or “Just do this…,” the odds are they are wrong.

Demand for excessive conformity

The same standard may not always apply equally in all situations. What worked great on your last project may be a disaster on this one. If Bob and Alice are hugely productive with Eclipse, it might wreck Carol and Ted. They prefer IntelliJ or TextMate or vi.^[24]

Insensitivity to contextual nuances

Formal methods are geared to the typical, not the particular. But when does the “typical” really ever happen? Context is critical to expert performance, and formal methods tend to lose any nuances of context in their formulations (they have to; otherwise, it would take thousands of pages just to describe how to get coffee in the morning).

Confusion between following rules and exercising judgment

When is it OK to break the rules? All the time? Never? Somewhere in between? How do you know?

Mystification

Speech becomes so sloganized that it becomes trivial and eventually loses meaning entirely (for example, “We’re a customer-focused organization!”). Agile methods are fast losing effectiveness because of this very problem.

Formal methods have other advantages and uses but are not helpful in achieving these goals. Although it may be advantageous to establish baseline rules for the lower skill levels, even then rules are no substitute for judgment. As ability to judge increases, reliance on rules must be relaxed—along with any rigid institutional enforcement.

Don’t succumb to the false authority of a tool or a model. There is no substitute for thinking.