More on this book
Community
Kindle Notes & Highlights
Read between
February 15 - May 8, 2018
Systematic design excluding intuition yields pedestrian follow-ons and knock-offs; intuitive design without system yields flawed fancies. How to weld intuition and systematic approach? How to grow as a designer? How to function in a design team?
The design process is not well understood either psychologically or practically. This is not for lack of study. Many designers have reflected on their own processes. One motivation for study is the wide gaps, in every design discipline, between best practice and average practice, and between average practice and semi-competent practice. Much of design cost, often as much as a third, is rework, the correction of mistakes. Mediocre design provably wastes the world’s resources, corrupts the environment, affects international competitiveness. Design is important; teaching design is important.
In retrospect, many of the case studies have a striking common attribute: the boldest design decisions, whoever made them, have accounted for a high fraction of the goodness of the outcome.
Everything has been composed, just not yet written down.
For most human makers of things, the incompletenesses and inconsistencies of our ideas become clear only during implementation. Thus it is that writing, experimentation, “working out,” are essential disciplines for the theoretician.
In fact, Royce introduced his waterfall as a straw man that he then argued against, but many people have cited and followed the straw man rather than his more sophisticated models. I made that mistake myself in my younger days, and publicly repented of it later.
The hardest part of design is deciding what to design.
For a while, this frustrated me sorely: “Why can’t he make up his mind as to what he wants? Why can’t he tell me all at once, instead of one bit a day?” Then, slowly, I came to realize that the most useful service I was performing for my client was helping him decide what he really wanted.
A chief service of a designer is helping clients discover what they want designed.
The most potent reason to study design history is to learn what doesn’t work, and why.
Often the original proponent of a theory or technique understands its promise, its liabilities, and its proper domain more clearly than his later disciples. Less gifted, more fervent, their very fervor leads to rigidity, misapplication, oversimplification.
One obvious injury done by accepting the Rational Model is that we mis-educate our successors. We teach them modes of working that we ourselves do not follow. Hence we leave them unaided in arriving at their own real-world working modes.
The Waterfall Model is wrong and harmful; we must outgrow it.
In the building of the IBM Operating System/360, requirements were initially set by a large committee from the Marketing Division, following a process and producing a result just like that described. As Project Manager, I had to reject the requirements document as totally impractical and have a quite small team of architects, marketers, and implementers extract the essence.
Requirements proliferation must be fought, by both birth control and infanticide.
Clearly, it is the necessity for contracts, whether within an organization or between organizations, that forces the too-early binding of goals, requirements, constraints. Everyone recognizes the fact that these must later be changed. (This opens new opportunities for wrongdoing: “Low-ball on the contract; make it up on the change orders.”) So it seems that the necessity for contracts best explains the persistence of the Waterfall Model for designing and building complex systems.
The pressure for a complete and agreed-upon set of requirements comes ultimately from the desire—often, an institutional demand—for a fixed-price contract for a specific deliverable.
So the bazaar is populated with many “vendors” offering their digital wares electronically. Many buyers, with their votes, pay recompense in a prestige communicated electronically throughout a worldwide community.
What a wonder is this gift-prestige culture! How unlike crass work-for-money, claim-my-intellectual-property-rights! What a new model for other societal activities!
One sees this pattern—physical isolation, small teams, intense concentration, and leadership by one mind—repeated again and again in the design of truly innovative, as opposed to follow-on, products:
I once asked Kenneth Iverson, Turing Award winner and inventor of the APL programming language, “Why is APL so easy to use?” His answer spoke volumes: “It does what you expect it to do.” APL epitomizes consistency, illustrating in detail orthogonality, propriety, and generality. It also epitomizes parsimony, providing many functions with few concepts.
A classic 1970 paper by Torrance showed that dyadic interaction produced twice as many original ideas, produced ideas of twice as much originality, increased enjoyment, and led subjects to attempt more difficult tasks.
Examples abound. Aristotle believed he could discover science deductively by reasoning; hence heavier objects would fall faster than light ones. Galileo believed that experiment was necessary and had the temerity to challenge Aristotle’s ancient authority.
Empiricists believe that humans will inevitably make mistakes: in defining objectives, in software architecture, in implementation in objects (algorithms and data structures), and in realization in code itself. This firm faith in fallibility prescribes a design methodology that includes design, early prototypes, early user testing, iterative incremental implementation, testing on a rich bank of test cases, and regression testing after changes.
An articulated guess beats an unspoken assumption.
When you specify something to be designed, tell what properties you need, not how they are to be achieved.
Style is a set of different repeated microdecisions, each made the same way whenever it arises, even though the context may be different.
Originality is no excuse for ignorance.
He who seeks originality is apt to find novelty, but not permanence of delight. On the other hand, he who seeks to make designs that really work is most apt to come up with new designs of enduring value, almost as a by-product.
For real pleasures give satisfaction (satis = “enough”). One gets enough food, enough sleep, enough work, enough play, enough lovemaking. The perverted, however, always seeks a new delicacy, a different taste, a progressive weirdness.
The professional, I would suggest, is apt to be familiar with the trees, doesn’t see the woods, and is slow to ask, “Does what I am doing make sense in the large?” To paraphrase Thomas Jefferson, the professional is often so preoccupied with doing the thing right that he fails to stop and ask, “Am I doing the right thing?”
Success is dangerous for the professional designer. Failure stimulates analysis, scrutiny, rethinking. Success stimulates confidence both in design technique and in oneself. Both trusts may be misplaced.
For designers to get the most learning from each design experience, they need to document how it evolves: not only the whats of the design, but also the whys by which it was reached. Moreover, such a rationale document is a priceless aid to system maintainers; it prevents many ignorant mistakes. Documenting trajectories and rationales is much harder than it at first appears.
We see this pattern again and again in the log. Design work doesn’t just satisfy requirements, it elicits them. Our experience resonates with Schön’s theory in Chapter 3. A good design process will encourage this phenomenon, rather than suppress it.
As to design itself, we are concerned that if designers use a structured annotation or software tool during design, it will restrict the ease of having vague ideas, impeding conceptual design. In much in the same way, a CAD tool is too precise for the quick exploration of creative ideas, whereas sketches allow the designer to be vague.
By its very nature, a product process “fights the last war,” encouraging tactics that have worked in the past and discouraging those that have failed.
Even when a really new product is not vetoed, consensus mechanisms often take off the sharp edges by forcing compromises. But the sharp edges are the cutting edges!
Product processes grow, and as with all bodies of rules, each mistake-experience begets new rules or new approvals to prevent repeats.
There are few barriers to the birth of such extra rules, and, once they are born, there are no forces for their elimination until a crisis comes. By the very nature of things, bureaucracies become more Byzantine, processes heavier, and organizations less nimble as they succeed and grow.
The engineers had always conscientiously and scrupulously followed IBM’s official Corporate Product Procedure, as documented in a manual of more than 100 pages. Successful project managers in other labs made bold “exceptions” to the procedure rules at the right times; the secret to success was choosing wisely!3 I sent such an experienced procedure manipulator to manage the project. He enabled the strong talent there to realize its potential. The S/360 Model 20 became phenomenally successful.
Finally, consensus processes starve innovative design by eating the resource. Consensus building takes meetings, lots of meetings. Meetings take time, lots of time. Great designers are few and far between; their time is exceedingly precious.
The trick is to hold “process” off long enough to permit great design to occur, so that the lesser issues can be debated once the great design is on the table—rather than smothering it in the cradle.
Product design and release processes cannot turn good designers into great ones. They rarely produce great designs without a great designer. But the disciplines imposed can bring up the low end of the design curve and improve the average performance of the art. That’s nothing to sneeze at.
Schön strongly disagrees with Technical Rationality on this point. He argues that all professional skills are mastered by critiqued practice. He argues that this is true of medicine, law, the ministry, architecture, art, music, social work, and indeed engineering.
Effective education in design styles will have the pupil doing a well-constrained computer architecture in the style of Cray, a fugue in the style of Bach, or a building in the style of Wren. A knowledgeable and discerning mentor will then point out stylistic inconsistencies and critique the overall excellence of the design for its constrained objectives.
All too often a manager recruiting new designers assesses them subconsciously on the criteria for the manager’s own job—“Could he do well the job I’m doing?” This favors the articulate, the leader, the person who will be effective in meetings. It tends to overlook the introvert, the slow-spoken,
and especially the unconventional. But brilliant designers come in these packages, too! (I do not assert that brilliant designers are more likely to come in such packages. I don’t know.) We managers overlook these gifted ones to our great loss, theirs, and society’s.
The first task for growing designers, as opposed to managers, is to craft a proper career path for them, one whose compensation and sociological status reflect their true value to the creative enterprise. This is commonly called the dual ladder. I have treated this elsewhere; here I only repeat that it is easy to give corresponding salaries to corresponding rungs (and market forces tend to make that happen), but it requires strong proactive measures to give them equal prestige: equal offices, equal staff support, reverse-biased raises when duties change.
But I am a believer in formal education—a good teacher who carefully prepares a balanced overview of a subject can improve my learning efficiency by a factor of two or more and can quickly give a balance and perspective that would require studying literally dozens of journals.
My most productive single act as an IBM manager had nothing to do with product development. It was sending a promising engineer to go as a full-time IBM employee in mid-career to the University of Michigan to get a PhD. This action, which at the time seemed to a busy computer architecture manager to be just a quite incidental personnel activity, had a payoff for IBM beyond my wildest dreams. Ted Codd’s PhD prepared him for a research career; his research led him to invent the relational database concept and to receive a Turing Award.5 Relational databases have been the principal application of
...more
