Development Islands

DIGG IT!     3 Comments Published Sunday, June 14, 2009 at 10:06 PM .

In 1996 I found myself ocean kayaking in Patagonia Chile. Our group, 15 of us, would wake at 5am to paddle from point to point across many small island inlets on the 30 day kayaking trip. The experience really stuck with me as we had to be very careful watching the weather conditions whenever we crossed open water. Crossings are the most dangerous element of ocean kayaking as you are exposed and weather can rapidly change for the worse. As strange as it sounds, this experience is identical to management of risk in a software development project. This model, development islands, has provided me a great way to think about software projects and the risk bearing decisions within the development process.

I have always found it ironic that in order to make progress writing software, you actively need to destroy/break the software you already wrote to make progress. At any point during development, 95% of the time software is in a non-working state becasue as you code, software clearly is broken. These areas during development I call crossings and the islands are the safe stable builds within a project. Looking at the larger picture software projects can be thought of as a large series of crossings between islands (stable builds) heading towards an unknown island where everything works perfectly. Here is a picture to help:



Obviously a project starts somewhere and makes build after build until it is complete. Along the way the project can fork into several parts so teams can work on aspects in parallel or at times things can fail. With every crossing you get closer and closer to this ideal endpoint yet at every part of development the project is at risk.

In looking at the larger picture, the ideal case is to make many small crossings where the build stays functional as much as possible. I do not believe that a project should ever reach an unworking state and that a developers role is to constantly have a safe island to return to and begin another crossing should one fail. Under this model the crossings represent feature/aspect development time and help you think about the many decisions on how a project gets broken apart. I use todo lists to define these crossings in advance of development but seeing things like this really changes the strategy. Breaking development tasks down into the smallest possible crossing becomes the key to the system.

How quickly can you get part of this problem solved into a stable build?
Can you build part of the project without the larger whole and integrate it in later?
Is this a component that I can license/reuse to save me development risk?

So next time you crack open a project, think about it in terms of Development Islands. Development Islands has changed how I think about projects, how I plan them, and how I executed them in development. Hopefully it will help you too.

And next time you get the chance go ocean kayaking, you will see what I mean. :)

cheers,

Ted :)

---