Some projects are hard, and the requirements are mysterious. They’re the kinds of things that look fine when you start, but sooner or later you get into some really nasty details. Should the third level of XML be in this format or that? Do they want us to use this URL scheme or that one? Are these screens different from those ones, or should they be combined?
You can spend a lot of time worry about these issues. Calling people, talking, whiteboarding, writing documents, seeking buy-in… or you can deliver something. Obviously you won’t delivery the perfect thing, or even a fraction of the perfect thing. At least not first time. But you will deliver something, and you can use that something to make further steps. Suddenly people see something tangible, and it really clarifies things. One class of questions suddenly becomes unimportant, and pertinent questions jump right out. Delivery beats analysis.
This is of course the basis of iterative development. But it’s also the basis of the Lean Startup approach. This is about discovering the right business model by trying out some rough ideas, rather than (say) commissioning a whole lot of market research which is entirely theoretical.
Anything novel that’s worth doing is hard. We can worry about that, or we can start discovering the reality through direct experience.
niksilver.com 