Begin at the beginning

For years I’ve been talking about “working from beginning to end”. It’s a common pattern in systems I see that developers begin to code functionality from somewhere other than the entry point to a system (e.g. the GUI). This approach increases integration difficulties. If the programmers keep saying things are done when they don’t actually work, this may be what’s going wrong.

A few years ago when I was doing test-driven development I experimented with working from the back end of the system to the front. Sometimes this works out ok, but sometimes you can’t actually get to the front end neatly. Somewhere early in the course you take a wrong turn and it gets difficult to find your way after that. I found what happened was that I spent a lot of time writing tests and code that turned out not to be needed.

Working from the front end (i.e. user interface for most applications), which is the “client” you have to serve with your code, is much more efficient. I think this is what you would expect when you reason it through. The client expects a certain service to be performed on its behalf. When we know what the service is we can write tests that “demand” the service be provided by failing when it isn’t. We can then implement the service.

This takes us to a new place in the system, perhaps one layer further in (especially if we use mock object testing). And we have now established what services we require of this layer, so we repeat the process until we reach already-implemented services such as the database.

If you work from the back end first, you’re implementing speculatively.

There is a related but more serious problem that can occur in larger teams, where more than one programmer (or pair of programmers) work on the tasks that make up a story. The problem is the formation of islands of functionality that don’t add up to a fully complete story. These form because each pair picks off a task from the story and implements it, but without connecting it correctly (or at all) to adjacent components (if they have even been implemented). This can leave the last task with a large integration problem, but is more likely in my experience to leave a story that is actually incomplete. By progressing from the beginning in a disciplined way, it’s much easier to finish a story that hangs together properly.