Always design a thing by considering it in its next larger context-a chair in a room, a room in a house, a house in an environment, an environment in a city plan.
Eliel Saarinen
Also, my problem-solving modalities are strange. I often perceive patterns where nobody else does, but equally often miss clues that are right in front of my nose. I've come to rely upon inspiration for getting through complex thickets, with only small help from observation and reasoning.
I said all that to explain why I've had a longstanding fascination with methodology. Wikipedia's definition:
Methodology is the study of the methods involved in some field or endeavor, or in problem solving. Most sciences have their own specific methodology. Methodology is sometimes used synonymously with "method", particularly a complex method or body of methods, rules, and postulates employed by a discipline. Some usage arbiters regard this usage as pretentious and questionable. In software engineering and project management, a methodology is a codified set of recommended practices, sometimes accompanied by training materials, formal educational programs, worksheets, and diagramming tools.
Wikipedia also has a reference to Buchler's "The Concept of a Method":
In methodology, the power of a method is inversely proportional to the generality of the method, i.e.: the more specific the method, the more powerful.
Examples:
very specific (very powerful)confirm presence of blood with luminol;
somewhat specificfind, then control key variables to make an experiment reproducible. make hypotheses, then try to disprove them; form a question, the answer to which will divide the problem space into two subspaces of about equal size; Occam's razor: all else being equal, the more likely hypothesis is the one with fewer assumptions; measure with micrometer, mark with chalk, cut with axe;
rather general (not very powerful)the exception proves the rule; blame your predecessor; when in doubt, cut it out; to understand something is to stand under it; false dichotomy, as "there are two kinds of people in the world"
The world of engineering is in transition between the Information Age and the Knowledge Age. In this chaotic time, we encounter growing amounts of novelty.
Now, novelty is disquieting; we like what we are used to. We can tolerate a bit of novelty at a time, as long as we can liken it to something we know, or fit it into an existing framework. The problem is that we are facing lots of novelty, more all the time, and we don't know how to deal with it.
Methodologies-truly, more than methods, and not pretentiously so-take the point of view of moving up the ladder of abstraction. As in the Saarinen quote above, methodologies enable us to understand that a chair is not floating in space; it is to exist in a room, which itself exists as part of a floor plan, in a house; and so on.
There are several methodologies in the world of software engineering. Each has its proponents, its strengths and weaknesses. Those who follow them understand their power and limitations.
In electrical engineering, there are some methodologies that make it possible to make the "powers of ten" scale trip from conceptual block diagrams to chip features with reasonable speed and consistency.
Few methodologies exist in the world of mechanical design and manufacturing. The materials and pheonomena seem to be too varied to admit of a general approach. What we have, typically, is "The Way We Do Things around Here"-TWWDTAH. It's usually an approach that grew organically in response to demands, and is maintained for its historical consistency, not because it's the best way to do things.
In most companies, the best feature of TWWDTAH is that it usually works; the next best feature is that if you follow it, you don't get any flak from management.
Its worst feature is that it works-and has rarely been optimized. There's no reason for seeking a better way, and plenty of inertia to cause people to ignore proposals to do so.
One of the most useful roles that engineering software technology has played in recent decades has been to force organizations to consider their methods and workflow. Bringing in a 3D CAD system, for example, obsoletes some functions, and introduces others. It exposes parts of processes, along with their flaws, that were hidden hitherto.
It upsets the applecart.
You, dear reader, have many testimonies to the truth of these observations, I'm sure. (By the way, I welcome them-write me at [email protected], or submit them to my new website, The EIM Coffeehouse, at http://eim.squarespace.com.)What's to be done?
My recommendation: In an enlightened organization, a new title: Person in Charge of Finding a Better Way. Reports to the VP of engineering. Has the authority to look at anything, and to persuade people to do things differently or try something new.
In more rigid companies: Get a weekly lunch group of like-minded people together to consider new ways, new technologies, and to learn the principles of "influence without authority." (T. E. Lawrence, "Lawrence of Arabia," had a lot to teach on that topic; worth researching.)You can make things better. All it takes is a little faith, some planning, and some action.Dr. Joel Orr is VP of business development for KollabNet, Inc. (www.kollabnet.com). Write to him at [email protected]. Visit his new website, "The EIM Coffeehouse," at http://eim.squarespace.com.