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日 星期四
2010年11月25日 星期四
2010年11月24日 星期三
2010年11月21日 星期日
2010年11月20日 星期六
2010年11月19日 星期五
2010年11月18日 星期四
2010年11月11日 星期四
2010年11月5日 星期五
2010年11月3日 星期三
2010年10月18日 星期一
Justin.tv - Startup School - Watch Startup School on October 16th
via justin.tv
Zuck spoke at YCombinator's Startup School (the video is embedded below).
2010年10月15日 星期五
2010年10月14日 星期四
2010年10月13日 星期三
7 Freely available E-Books/Guides I found essential for .NET Programmers and Architects
Check out this website I found at blogs.msdn.com
Too many books too less time.
2010年10月12日 星期二
2010年10月8日 星期五
Sony Drops Out of Climate Change Campaign After Exploding Kids Ad | Fast Company
via fastcompany.com
WTF?!
2010年10月7日 星期四
2010年10月6日 星期三
2010年9月27日 星期一
2010年9月18日 星期六
Enno de Kroon's Photostream
Eggcubism - in progress. Stage may 13.. just about finished Best seen...
Uploaded on May 11, 2010
via flickr.com
Awesome!!
2010年9月17日 星期五
Your Credit Cards Will Never Be the Same Again: Meet Card 2.0 [VIDEO]
via mashable.com
very interesting idea!
2010年9月16日 星期四
2010年9月14日 星期二
2010年9月12日 星期日
2010年9月10日 星期五
2010年9月9日 星期四
2010年9月3日 星期五
2010年8月28日 星期六
Your Brain on Computers - The Unplugged Challenge - Interactive Feature
via nytimes.com
Funny!! The New York Times Unplugged challenge. How many days you can survive without your digital devices.
2010年8月27日 星期五
2010年8月26日 星期四
2010年8月25日 星期三
How to Open Your Publisher Account on New Digg 4
It looks like twitter, but it could help you focus on your target followers.
YoYoFactory Present: Jensen Kimmitt 2010 World yoyo Contest 1A 1st Place
via youtube.com
Wow... No wonder he is the champion.
Disabling spindump on OSX to prevent slowdown after a crash – Yan Pritzker
Disabling spindump on OSX to prevent slowdown after a crash
Update: it’s better to use a spindump script that sleeps, otherwise launchd keeps trying to restart it every ten seconds. Thanks to Steve Ryner for the script. And yes, it’s very simple but here it is :-)
#!/bin/sh while true do sleep 60000 doneSometimes when things crash on OSX (biggest offenders: Quicktime, and Safari playing flash movies), a program called
spindumpfires up. This offensive piece of bad engineering thinks its ok to eat 100% of my cpu and thrash my disk just to catalog what happened.While this is a great idea in theory, and I’m sure it helps Apple engineers debug problems, it does absolutely nothing for me trying to bring my machine into a usable state. Fighting spindump for resources while I try to kill the hanging program is not fun. And many people on online forums seem to think the same. Most of the time I’m barely able to pull up the activity monitor and nuke spindump before it goes off to lala land never to return. Granted things don’t crash often, but when they do there is hell to pay.
Well, we don’t have to submit to this madness anymore. It occurred to me that I could simply rename the spindump executable so that OSX could not find it. So I renamed
/usr/sbin/spindumpto/usr/sbin/spindump.disabled. I had to wait for my first crash in order to verify that this didn’t break anything, and sure enough I had a quicktime crash just the other night. The system promptly recovered from the crash and did not slow down as previously. Mission accomplished!Apple is a company built on user experience. But
spindumpis one of the worst user experience violations in OSX. I know there may not be an easy way around it, but certainly at the very least changing the priority of this process so that it’s not able to eat all system resources may be a step in the right direction. I hope to see an improvement in future versions of the operating system. Until then, spindump is dead to me.
via yanpritzker.com
2010年8月24日 星期二
2010年8月23日 星期一
Elegant Code » Book Review: Facts and Fallacies of Software Engineering
Having this book on my shelf for quite some time now, I finally decided to to make my way through reading Facts and Fallacies of Software Engineering written by Robert L. Glass. As the title already implies, this well-established author lays down 55 facts and 10 fallacies about software engineering based on his half a century experience in the field.
The facts are divided in four categories: management, lifecycle, quality and research. The fallacies are split into three categories: management, lifecycle and education. Each of these categories have their own more specific sub-categories in which these facts and fallacies are classified. This way its easy to pickup the content about a particular topic of choice. Although I read the book from cover to cover, it isn’t required to do so. All facts and fallacies can be read on their own but occasionally the author refers to the discussion of other facts/fallacies in the book.
All facts and fallacies are laid down using the following structure:
- The fact/fallacy itself is presented and discussed.
- After which the controversies about a particular fact/fallacy are presented.
- Finally, a list of books and articles are enumerated that were a source of information regarding the fact/fallacy. Some of these sources are ancient, some of are more recent.
Here’s the list of facts:
People
- The most important factor in software work is the quality of the programmers.
- The best programmers are up to 28 times better than the worst programmers.
- Adding people to a late project makes it later.
- The working environment has a profound impact on productivity and quality.
Tools and Techniques
Hype (about tools and technology) is a plague on the house of software. New tools and techniques cause an initial loss of productivity / quality. Software developers talk a lot about tools, but seldom use them. Estimation
One of the two most common causes of runaway projects is poor estimation. Software estimation usually occurs at the wrong time. Software estimation is usually done by the wrong people. Software estimates are rarely corrected as the project proceeds. It is not surprising that software estimates are bad. But we live and die by them anyway! There is a disconnect between software management and their programmers. The answer to a feasibility study is almost always "yes". Reuse
Reuse-in-the-small is a solved problem. Reuse-in-the-large remains a mostly unsolved problem. Reuse-in-the-large works best in families of related systems. Reusable components are three times as hard to build and should be tried out in three different settings. Modification of reused code is particularly error-prone. Design pattern reuse is one solution to the problems of code reuse. Complexity
For every 25 percent increase in problem complexity, there is a 100 percent increase in solution complexity. Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical. Requirements
One of the two most common causes of runaway projects is unstable requirements. Requirements errors are the most expensive to fix during production. Missing requirements are the hardest requirements errors to correct. Design
Explicit requirements ‘explode’ as implicit requirements for a solution evolve. There is seldom one best design solution to a software problem. Design is a complex, iterative process. Initial design solutions are usually wrong and certainly not optimal. Coding
Designer ‘primitives’ rarely match programmer ‘primitives’. COBOL is a very bad language, but all the others are so much worse. Error removal
Error removal is the most time-consuming phase of the lifecycle. Testing
Software is usually tested at best to the 55 to 60 percent coverage level. One hundred percent test coverage is still far from enough. Test tools are essential, but rarely used. Test automation rarely is. Most testing activities cannot be automated. Programmer-created, built-in debug code is an important supplement to testing tools. Reviews and Inspections
Rigorous inspections can remove up to 90 percent of errors before the first test case is run. Rigorous inspections should not replace testing. Post-delivery reviews, postmortems, and retrospectives are important and seldom performed. Reviews are both technical and sociological, and both factors must be accommodated. Maintenance
Maintenance typically consumes 40 to 80 percent of software costs. It is probably the most important software lifecycle phase. Enhancements represent roughly 60 percent of maintenance costs. Maintenance is a solution– not a problem. Understanding the existing product is the most difficult maintenance task. Better methods lead to more maintenance, not less. Quality
Quality is a collection of attributes. Quality is not user satisfaction, meeting requirements, achieving cost and schedule, or reliability. Reliability
There are errors that most programmers tend to make. Errors tend to cluster. There is no single best approach to software error removal. Residual errors will always persist. The goal should be to minimize or eliminate severe errors. Efficiency
Efficiency stems more from good design than good coding. High-order language code can be about 90 percent as efficient as comparable assembler code. There are tradeoffs between optimizing for time and optimizing for space. Research
Many researchers advocate rather than investigate. And the list of fallacies:
Management
- You can’t manage what you can’t measure.
- You can manage quality into a software product.
People
Programming can and should be egoless. Tools and Techniques
Tools and techniques: one size fits all. Software needs more methodologies. Estimation
To estimate cost and schedule, first estimate lines of code. Testing
Random test input is a good way to optimize testing. Reviews
"Given enough eyeballs, all bugs are shallow". Maintenance
The way to predict future maintenance costs and to make product replacement decisions is to look at past cost data. Education
You teach people how to program by showing them how to write programs. Although this book has been published in 2004, the topics that are discussed in this book very much apply today and probably many years to come. I personally got the most from the facts about people, estimation, testing and maintenance. I really enjoyed reading this fascinating book and I encourage you to pick it up as well. Awareness of these facts and fallacies, whether you agree or disagree with them, is the first step to improving our craft.
via elegantcode.com
It's great book. recommend!!
2010年8月22日 星期日
訂閱：
文章 (Atom)
