• euphoria
• I can do no wrong
• an adrenaline rush
• tightly focused; no competing thoughts; no distractions
• everything makes sense
• orgasmic
• everything's possible
• time flows differently
• unusual confidence
• unusual courage
• unusual enlightenment
• performing to the best of my ability
• performing at the highest efficiency

When the engineer enters the zone, innovation takes place -- it becomes an irresistable force.

I was required for a class to read Tracy Kidder's The Soul of a New Machine (a classic in the field!) and write an essay on lessons learned relevant to systems analysis. Just in case you've never heard of this book, it documents the development in the early 1980s of a 32-bit computer (no great shakes by today's standards), and the company (Data General, now out of the computer manufacturing business and recently bought out by EMC) who did it.

Kidder's book is a classic meeting of the irresistable force (innovation) and the immovable object (fear of failure). Here's what I felt I learned:

"Engineers provide most of the ideas for new products. After all, engineers were the people who really knew the state of the art and who were therefore best equipped to prophesy changes in it."

Even young engineering students readily recognize that "creativity" and "problem-solving skills" are desirable in engineering professions. On the other hand, young people are seldom likely to see themselves as the kind of creative people they expect engineers to be. We try to instill this sort of creativity by assigning projects in most classes; even requiring a senior project or a term project before graduation.

The sort of creativity required in the workplace, however, is constrained by market forces (and time limits associated with those forces). There's not usually time for going down blind alleys, despite the old engineering axiom "there's never time to do it right; there's always time to do it over."

We've learned that the practice of prototyping is in itself no guarantee of doing the job right; it may even lead to embedded mistakes that have to be fixed later. Since the rewards of prototyping often outweigh the risks, we sometimes depend on them heavily.

Though prototyping may replace some of the creative environment otherwise lost to a market-window deadline, what you end up with is not optimal creativity. No time for blind alleys, low tolerance for error, inconsistent documentation -- all good reasons for great ideas to be lost to history.

"You did not have to be the first company to produce the new kind of machine; sometimes, in fact, it was better not to be the first. But you had to produce yours before the new market really opened up and customers had made other marriages. For once they are lost, both old and prospective customers are often gone for good."

Despite the engineer's feeling that failure is a Bad Thing in and of itself, it's the need to get through that market window that is the principal driver behind fear of failure. Enough mistakes and you miss the window, the opportunity is lost, and all the work up to that point has gone to waste.

So we keep pushing throughout the project to hit the window. Tasks we see as secondary, such as documentation, get left behind in the push. We base the shipping schedule on "the earliest date we can't prove we won't be finished." This was the principal fear of the Eagle hardware and software designers. All their other fears of failure stemmed from it:

• the big mistake (discovered late and requiring a major redesign)
• flakiness (due to a misstep in a process whose steps can't be reproduced in the same order)
• the boogeyman (that dark, nameless fear that the thing won't work at last)
• the kludge (a temporary repair, not properly documented, that isn't fixed the right way later)

Samuel Florman writes in The Civilized Engineer that failures of these types are particularly hard to avoid in new product design because of what Galileo referred to as "the tasting of new fruit." If we've never done it before we will only do it right the first time by accident, even if all the technology we need to do it right the first time is in place.

Kidder hinted that the market window the Eagle team was shooting for was self-imposed, once it became clear that no competitor would meet the same window any sooner than Data General. If there is a lesson to be learned from history, it is to at least plan for *some* failures and *some* gathering of creative knowledge in the project schedule.

I've known managers who have done that -- for their own use only. The engineers would be held to an original schedule, just so that slop built in for management purposes wouldn't entice the engineers to drag their feet early on. My heart tells me this is yet another form of "mushroom management," but a workable alternative isn't clear to me yet. The manager's intent is generally to avoid any negative outcome that can delay an innovation.

Negative Patterns

A negative pattern (or, antipattern) can be stated: "avoid this." After all, a desirable action would probably be stated, "do this." :-) In design, we aren't always sure what the negative patterns are, or what their consequences will be. (That's one of the reasons for prototyping.) We can, as part of the development process, introduce negative patterns to assess their effects. Benefits include:

• conversion of intuitive knowledge to design knowledge
• location of design defects; improvement of quality

A negative pattern has the potential for a positive outcome. We can change not only the effects of the specific pattern, but the way we create patterns in general. To take advantage of negative patterns, here are some things we can do:

1. Fault seeding. Insert a defect deliberately, to force the design to be less flexible, less user-friendly, etc.
2. Surveying stakeholders. Start with the people working on the current project, or anyone nearby who's worked on something similar. Find out what they've been bitten by before, and the magnitude of the risks.
3. Modeling. There are mathematical and statistical techniques that can be employed for assessing many types of electrical, mechanical, industrial and structural systems.

Here are some negative patterns seen in the software and computer systems worlds (with solutions in parentheses). Some will have analogs in other fields:

• single point of failure
• deadlocked cycling
• excessive interrupts (complete what's been started)
• excessive overhead (optimize initialization)
• over-specified inputs (generalize parameters)
• excessive coupling of functions (decouple them!)

And here are some negative patterns in organizations:

• lack of/unreadable documentation
• misunderstood relationships between roles
• distractions
• backing off too far from constraints
• throwing resources at project overruns
• excessive overtime/sacrifice of vacation
• "mushroom management"

References

Negative Patterns in Design, http://www.users.globalnet.co.uk/~rxv/sqm/pitfalls.htm
Florman, S. The Civilized Engineer. St. Martin's Press, 1989. ISBN 0-31202-559-9
Kidder, T. The Soul of a New Machine. Back Bay Books, 2000. ISBN 0-31649-197-7