Planning isn't free

I've got a confession to make: I secretly enjoy rewriting code when requirements change. I get to think again about what I was doing and my assumptions, tidy up the lingering technical debt, make a few performance optimisations and abstract things a little bit so I don't have to worry about future change requests. More importantly, I get that warm agile development feeling of showing my customer a work in progress, using it to understand more about their requirements, and build a better piece of software.

This attitude horrifies some people. "What about the cost of the work you're throwing away," they ask. "Couldn't you have got it right first time with a bit more planning and spent less money?"

This misses an important point. Planning also has a cost.

Actually, it's got two costs. The first is the obvious: all that planning has to be done by someone. BAs, project managers, architects, development leads and stakeholders have to sit in meetings, write requirements, and draw diagrams. That's the obvious one. But the second is that stalling development activity to plan incurs an opportunity cost. Your development team isn't working on putting useful software in the hands of customers. At worst you're paying people to twiddle their thumbs and polish their CVs while you come up with the gold standard Plan To End All Plans. This might take place off the budget sheet, but it's a cost, and an enormous one. The market is running and you're standing still.

Now, I'm not saying don't plan. Planning is a useful activity. The difficulty is that planning has a steeply declining effort:reward ratio. Once you've got an idea of what you want to build you'll get more bang for your buck by iterating and stabilising than you will trying to sweat the details on paper. In fact, past a certain point planning offers negative return - creating detailed plans for things people find hard to understand without seeing them in action is a long and arduous road to spending a fortune on planning and a fortune on rework.

Don't fear changing your software. If you're really worried about the cost of change, then iterate in something low-fidelity like Balsamiq mockups before committing to writing real code. (If nothing else, most developers I've worked with far prefer being given a functioning prototype and told "make it work like this" than being given a 300-page requirements document)

Instead, fear the very real financial and opportunity cost of too much up-front planning.