Get something real up and running quickly
Running software is the best way to build momentum, rally your team, and flush out ideas that don’t work. It should be your number one priority from day one.
It’s ok to do less, skip details, and take shortcuts in your process if it’ll lead to running software faster. Once you’re there, you’ll be rewarded with a significantly more accurate perspective on how to proceed. Stories, wireframes, even html mockups, are just approximations. Running software is real.
With real, running software everyone gets closer to true understanding and agreement. You avoid heated arguments over sketches and paragraphs that wind up turning out not to matter anyway. You realize that parts you thought were trivial are actually quite crucial.
Real things lead to real reactions. And that’s how you get to the truth.
The Real Thing Leads to Agreement
When a group of different people set out to try and find out what is harmonious…their opinions about it will tend to converge if they are mocking up full-scale, real stuff. Of course, if they’re making sketches or throwing out ideas, they won’t agree. But, if you start making the real thing, one tends to reach agreement.
—Christopher Alexander, Professor of Architecture (from Contrasting Concepts of Harmony in Architecture)
Get It Working ASAP
I do not think I’ve ever been involved with a software project — large or small — that was successful in terms of schedule, cost, or functionality that started with a long period of planning and discussion and no concurrent development. It is simply too easy, and sometimes fun, to waste valuable time inventing features that turn out to be unnecessary or unimplementable.
This applies at all levels of development and “get something real up and running” is a fractal mantra. It doesn’t just apply to the project as a whole, it is at least equally applicable to the smaller-scale development of components from which the application is built.
When there is a working implementation of a key component available, developers want to understand how it will or won’t work with their piece of the application and will generally try to use it as soon as they can. Even if the implementation isn’t perfect or complete at first, this early collaboration usually leads to well-defined interfaces and features that do exactly what they need to.
—Matt Hamer, developer and product manager, Kinja