Iterative, Test-Driven Development

Iterative, “test driven”, development.

Break your idea down into a number of simple “stories”, each of which describes a single chunk of activity which goes all the way through from the beginning to the end of a user’s experience with the software. Importantly a story is not a traditional “component” … but represents a complete, working but minimal slice through the functionality.

For example, a story could be “the user goes to our site at a URL and sees a page describing our idea” or, for a drawing program, “the user can create and save a jpg file” (even though that jpg file is just a blank canvas).

Once you have some stories, order them by importance. If you could only get one story working, what would be the most valuable? If you could only get two stories, which would those be?

Start on the most important story. As any particular story shouldn’t be too complicated, you can probably figure out fairly intuitively the components you need in order to make it happen. (If you can’t, you’re trying to fit too much into a single story.) Those components might be functions, they might be objects which have several methods (if so, ONLY worry about the methods of the object which satisfy the current story, ignore any others), they might be HTML forms or templates.

Now write AUTOMATED TESTS for the components you need for this story. Unit tests for the functions and objects. Ideally something like Selenium for the web forms.

Write code to pass the tests in a test-driven style … ie. write test, write code to pass test, refactor your code to eliminate redundancy, write next test etc. When one story is finished, start figuring out how to do the next most important and work on that.

Somewhere down your list of stories you have your minimum viable product: that is, the minimal thing which is worth releasing to your customers in order for them to give you feedback on whether this is useful to them. That is not necessarily just one story, it might be after the first three. Or the first ten. Whatever it is, once you hit it, release your product to the customers and start getting their reaction.

From now on you are in maintenance / iterative growth mode. You’ll be taking the feedback from the customer to rewrite and reorder the stories. While continuing to implement them according to your best, most up-to-date, sense of priorities. You’ll want to release new development to the customer as fast as reasonably possible so you can collect the feedback on your improvements too.

Don’t assume that one story has to equal one release, because you’ll be tempted to inflate your individual story to contain more than it should. But try to keep releases down to as few stories as possible so they can happen frequently : which maximizes both your information, and the customer’s sense of progress.