Let's say you've got a great idea. How do you make something of it? Chances are, that idea is a few words on a page, or a vague concept with a lot of promise. It needs refining, and clarifying, and improvement. It probably needs some feedback, and it definitely needs money. In short, it needs a lot of work.
The best way to get all of that done is through prototyping. This isn't a new idea (look for 20.5M+ Google hits), but it's surprisingly hard to do. Our ideas are precious, and we want to shelter them and improve them until they're ready to face the harsh light of reality and the cold critiques of our peers. Unfortunately, it turns out that this is exactly the wrong way to go about doing it. Innovators might do well abide to by the slogan "prototype early and often."
The intuition is that physical prototypes simultaneously reveal the weaknesses and gaps in our thinking while also effectively communicating the idea to others for feedback and extension. Building on that, it's no surprise that the most effective prototyping is quick and dirty; the drawers at Stanford's design school are brimming with post-it notes, pipe cleaners, and modeling clay. The emphasis is to convey the idea simply and inexpensively, but not for the reason you might expect.
Rapid prototypes DO allow designers to cycle through iterations quickly, improving an idea faster than they would if they built nice models for each design. They also save money. But just as importantly, "quick and dirty" prototypes communicate to colleagues that an idea is still open for discussion; they invite feedback and critique, and through that, improvement. More than once I've been told my research slides are "too pretty" - early ideas deserve simple presentation.
In this vein, one of the unofficial mottos of the design firm IDEO is "fail faster to succeed sooner." Stanford Professor Bob Sutton has similarly said that "creativity isn't about wild talent as much as it's about productivity. To find a few ideas that work, you need to try a lot that don't. It's a pure numbers game." Because rapid prototypes allow designers to move through more ideas that don't work, they're likely to hit on one that does faster than they would have if they wasted time (and money) perfecting each individual iteration.
And that's where computer science comes in. I attended a brunch a few years ago where I met a coder who had just finished hacking together a website that allowed people to design and sign up for contributions to potluck meals - we had actually used it to organize the brunch. It was a simple idea, but a great one, and he had put together a working implementation in just a few hours. Similarly, when Pandora wants to tweak their song recommendation algorithm, they simply switch a small subset of their users over to the new method and see how it performs. Easy.
Contrast that to one of my recent projects. I had a great idea for a new locking bicycle hub that would help prevent wheels from being stolen. I sketched up the idea, but then had to work hard to cobble together a non-functional prototype from hardware store parts. Looking forward, I might be able to find a machine shop to mill me the pieces I need, but then what? Getting it out and into bike shops is going to be no easy task. In the time I've spent trying to build my one prototype bicycle hub, I could have worked through a dozen functional iterations of an idea on the web.
While this ISN'T intended to diminish the difficult, time-consuming, and occasionally incredibly tedious work of writing and debugging code and launching products, the ability of coders to work through ideas and iterate through prototypes is orders of magnitude faster than those tied to the physical world. That means good things for the process of building ideas, as well as for the people that build them - which is why my daughter will (someday) study computer science.