Starting a project

There are many ways for a project to start. But I've found the successful ones eventually move to iterative development. Those that start out as a waterfall become iterative during a stabilization period, sometimes longer than the original development.[1]

Everyone may think they know exactly what they want a product to do at the beginning, but that always seems to change as everyone discovers what is possible. When too many features are rushed into a product simultaneously, instability results.

It is very tempting to fill a room with "stakeholders" to specify features for the product, rank them by importance, and estimate the effort for each. This exercise gives everyone a feeling that the project is under control. This is the first step of a waterfall.

Unfortunately, the next temptation is to make a quick prototype of each feature, with incomplete, buggy implementations. A long stabilization then tries to decide how all these individual ideas actually coexist in the same product.

Lightweight, agile methods (XP, Scrum) provide another way to keep a project under control: Continuous Integration.[2] At any hour of the day, you can get a stable version of the product from the repository. Every feature that is visible actually works. The most essential features were done first. All implemented features are reconciled with each other. You have a good record of how fast you are moving.

Here's my recipe for a more sensible beginning.

  1. Identify the customer. What does he do, and how does he do it right now? What software is he using, and what does he like or dislike about it? What are the biggest pains, the biggest gaps in the workflow? Where could you have the biggest impact?
  2. Compare your natural advantages. What are you good at? Who do you have? What code do you have? What special expertise do you have?
  3. Make a short list (five) of some of the biggest problems you could address, and a few ideas for how you might begin to tackle each. What would the be very first thing you could do that would be interesting to your users and relatively easy to write and test? What would best clarify what you want to do next?
  4. Evaluate longer-term contingencies. If these ideas work out, or do not, what might you do afterward? You'll appreciate the uncertainties more.

Make sure people who will be doing the actual work are involved. You should have an equal number of people who can identify with users, who could not care less how it is done.

Software design is essentially a conversation between user representatives (domain experts) who want to solve specific problems and programmers who know what is possible. It often feels more like a negotiation, but when the conversation works best, these minds find clever solutions that never would have occurred to one alone.[3]

The projects that really gel can usually come up with a single phrase that describes what they are trying to do. If that seems hard, then maybe you really have a collection of projects. Sub-projects can be isolated and iterated separately, while still continuously integrating with the others.

Footnote 1: [ Moving_to_iterative_development.html ]

Footnote 2: http://martinfowler.com/articles/continuousIntegration.html

Footnote 3: [ Software_Development_is_a_Negotiation.html ]

Bill Harlan, April 2008

Return to parent directory.