The mid-project hump

In every major project I’ve worked on over the last ten years, including the one I’m doing now, I’ve hit a psychological wall about half way through. The initial research and requirements gathering stage always flies by, because talking to people about great ideas is fun, and turning bad ideas into good ones is rewarding. The design stage – and I hope you have one – where the specification is written tends to go quickly too, because there is something tangible in those user interface mock-ups.

The problems start once I start writing code. I’ve always started implementation from the bottom up, developing the skeleton of the system, the database schema, the parts of the system where concurrency problems make my head hurt. I suspect that this may be why, about two months into any project, I’ve always found it incredibly hard to motivate myself. The problem is not seeing anything happen – what I’m working on might not get used in the product for months after I’ve finished it. Developing the user interface first can help, but there is a danger of ending up with a prototype that needs to be turned into a product, something that is rarely good for your health.

Lately, I’ve found that a way to motivate myself is to make tests my milestones in the initial coding stages. In parallel with building a subsystem I build throwaway implementations of the subsystems it interacts with. These aren’t mock objects – they’re fully-fledged but completely naive implementations that would never scale to real-world use, with instrumentation so test cases can be written. Each time the tests for a new piece of functionality are written and passing, I can check in and pat myself on the back.

This type of development has many names – test-driven, test-first, tracer-bullet – but for me it’s just a way of giving myself real goals during the most difficult stage of a project.