Sketches in product development

The NY Times Magazine this morning had a piece on Santiago Calatrava, my favorite practicing architect. Absolute genius. Several folks at work have lately been taking a bunch about the software development process. Sure, there’s a ton of life-cycle development models out there. But what works best for the web? The waterfall method is probably the most common to date.

What does software development have to do with Calatrava? The light bulb went on for me after reading this excerpt.

Unattached to any school of architcture, Calatrava draws like an artist and thinks like a scientist. “What is interesting,” he says, “is that the sketch is always spontaneous. If you keep drawing, you can preserve much of this spontaneity. You have an idea. You refine it through sketching.

The notion of sketches is what captured my attention about Calatrava. He iterates on ideas via sketches until he finds something that works. Iteration is absolutely opposite to how I’ve seen product developed in my years in software development. First somebody tells you what you’re going to build, then you build it. Whether it’s the right thing to build of not is usually not part of the equation. Iteration only comes after launch by working on the next version.

My group at work has started to experiment with this notion of sketching (or iteration) until we get at what we want to build. In theory, knowing what you’re going to build should make requirements and technical specification SO much easier.

Revolutionary? Hardly. Then why did we never come to this conclusion earlier? Probably because when developing for the web you can push new changes out far easier than a typical software or hardware company can – – next day. So why spend lots of time in a software development cycle when it’s easy to erase mistakes? Reduce or eliminate shitty ideas getting launched. How do you like them apples?

Sketch, then build!