2010年12月25日 星期六
2010年12月24日 星期五
To Innovate, You Need the Courage to Step Backward | Co.Design
To Innovate, You Need the Courage to Step Backward
The biggest ideas come only after you question why you're trying to innovate in the first place.[This is the first post in a new series by noted design writer Warren Berger. His most recent book, CAD Monkeys, Dinosaur Babies, and T-Shaped People: Inside the World of Design Thinking and How It Can Spark Creativity and Innovation, is out this month in paperback.—Ed.]
When we think of innovation, we tend to associate it with forward motion. We may envision it as a leap ahead—a radical breakthrough that happens quickly—or, more realistically, as a steady march forward, during which a series of small advances and refinements eventually lead to a desired outcome.
But in observing a number of leading designers and innovators over the past couple of years (including individuals such as Yves Behar, Bruce Mau, and Dean Kamen, and firms such as IDEO and Smart Design), what has struck me is how often these change-makers seem to be moving sideways and even backwards, in addition to moving forward. In my own head, I’ve started to think of this as a kind of “catalyst’s dance”—with the most common version of it being a nifty (and quite difficult) four-step.
The ability to question fundamentals has never been more important
More often than not, this dance begins with taking a step back—to reconsider existing realities, to challenge basic assumptions, and above all, to question everything. Designers seem to be particularly adept at questioning (hence the joke, How many designers does it take to change a light bulb? Answer: Does it have to be a light bulb?), but it’s also an ingrained behavior among all sorts of innovators, including the most creative business executives. (One recent study published in the Harvard Business Review found that a key characteristic of creative executives—and the one that seemed to have the greatest impact—was the inclination and willingness to question everything).
While this first “questioning” step may seem like an easy one, it actually can be quite difficult to ask basic “why” and “why not” queries. There’s pressure, particularly in business, to avoid any appearance of being naïve. And questioning established practices doesn’t always sit well with colleagues accustomed to doing things a certain way. Moreover, there’s an art to asking the right kinds of catalytic questions (which will be the subject of a future post). But difficult as it may be, in today’s volatile marketplace, the ability to step back, question, and rethink basic fundamentals—What business are we really in? What do today’s customers actually need or expect from us?—has probably never been more important.
Of equal importance is the second step of the catalyst’s dance—which might be thought of as a “step to the outside.” Design thinkers at IDEO and elsewhere have demonstrated the value of observational research in helping innovators to ferret out people’s deep unarticulated needs. While this practice is sometimes labeled with design terms such as “user understanding” or “empathic research,” I prefer the word applied by the author and design consultant Dev Patnaik—“caring.” At this second stage of the process, innovators must care enough about people’s actual lives and needs to be willing to step outside the corporate bubble and immerse themselves in an environment where they can watch and learn. Doing so will tend to yield fresh insights that begin to address those big questions previously raised.
While this “caring” phase is critical, it often doesn’t yield the big breakthrough idea right away. Anecdotal stories from innovators—supported by the latest research on creative thinking—suggests that truly original ideas tend to come from taking what we’ve learned and synthesizing it with other ideas, influences, and creative instincts. This is the “connect” stage, wherein elements and ideas that may seem unrelated begin to come together to form “smart recombinations” (to use a term coined by the designer John Thackara).
There is no shame in going backwards or sideways
Think of the innovative Nike Plus system: The company started by questioning its basic offerings and then proceeded to the “caring” stage (using ethnography to learn firsthand about runners’ on-the-go information needs), but it took another step for Nike to smartly combine a running shoe with an iPod. This third step in the dance can be thought of as a “step together” move—when everything comes together to form the new idea. Neurological studies tell us that some people are better than others at making these insightful mental connections, but all of us are capable under the right conditions of getting to big “aha” moments. When it happens, it may feel great—but it’s not the end of the dance.
The fourth step—after question, care, connect—is to “commit.” It’s at this point that the innovator takes a bold step forward, by giving form to an idea and actually putting it out there in the world. Whether it’s a sketch, a prototype carved from foam rubber, or a sophisticated CAD model, what matters is the act of quickly and unflinchingly giving form to an idea so that it can be passed around, evaluated, tested. This is perhaps the trickiest step of the dance. Given that most new ideas are imperfect and most prototypes flawed, the likelihood of a misstep is so high as to be almost a given.
Still, innovation is unlikely to occur unless the person or team behind the idea is willing to commit, without hesitation, to taking this uncertain fourth step. If it turns out the idea is not ready for prime time, it may be necessary to once again step back—and perhaps even to repeat the whole question-care-connect-commit cycle, in the effort to keep learning and refining. What the experienced innovator understands is that there is no shame in going backwards or sideways, and what might seem to be a setback is nothing of the kind—it’s just a step in the dance.
[Top image by Horia Varlan]
<div class="disqus-noscript">View the discussion thread.</div>
via fastcodesign.com
2010年12月16日 星期四
What's So Wrong With Quick and Dirty Code?
What's So Wrong With Quick and Dirty Code?
The twittersphere and blogosphere have been burning up (at least in my corner of the social graph) with the topic of clean code vs expediency. In essence, the question seems to be, “couldn’t we deliver software faster by not worrying too much about clean code?”
I think not. Consider these trivial examples from domains with which we are (mostly) all familiar:
- Could we not save a minute or so by not tying our shoes in the morning?
- Isn’t the kitchen more efficient if we never bother washing the dishes?
- Who has time for car maintenance? Isn’t it faster if we just proceed to work riding on bare rims, with black smoke belching forth from under the hood?
These questions suggest obvious misperceptions, ones which functioning adults in the modern age easily recognize as dangerous. But each of us had to learn avoid them at some point. And there are human beings (called children) for which the attendant dangers may not be so apparent.
The basic value proposition in QuickAndDirtyCode™ that I’m hearing is that it’s faster. But it’s important to recognize that the risk in each of these mis-perceptions isn’t merely of the moderate, inverse-linear kind. If I’m an idiot and think I don’t need to tie my shoes when I go out, the danger to me is not merely that it will actually take longer than if I had tied them. The danger is far worse: I could stumble on the stairs, injure myself, and impair my ability to go out for a long time.
The risk in using unwashed dishes and utensils in the kitchen isn’t simply that it actually takes longer to cook with them. In point of fact it might be faster in some situations. But there exists the very real risk of laying the entire family low with food poisoning, which is a major slowdown to many people, not just one.
And if you drive your car on the rims, you’ll be walking soon, if you’re lucky. In the meantime, you’ll lose time, equipment and maybe worse.
The idea that quick, dirty and “expedient” coding edges past clean code in the short term is a terrifically naive one. Software projects (and their several parts) tend to grow when they are successful. That’s just what they do. As the codebase grows, the risk in not writing clean code isn’t merely that it ultimately may take a bit longer; dirty code can sink a project. Dirty code eventually dooms projects to one of two outcomes: a complete re-write, or total failure in the form of abandonment of the project’s goals. Clean code helps us steer clear of these two outcomes by offering us the chance to build better software on top of what we’ve built in the past.
So what do you do if you’re new to software development, and clean code doesn’t come naturally? It seems clear to me that until we know enough to take the time to tie our shoes, we are not ready for the Big Time. If we won’t wash the dishes, we shan’t do much cooking. If we won’t get the car fixed, we won’t drive very far. And if we don’t learn to write clean code, we won’t be delivering much working software. For the less experienced developer, there really is no viable alternative: learn to write cleaner code.
- Posted on Friday, December 10, 2010
via joelhelbling.com
Well said Joel.
2010年12月15日 星期三
2010年12月14日 星期二
2010年12月13日 星期一
2010年12月9日 星期四
訂閱：
文章 (Atom)
