Planning is Hard - Plan Better

There's a quote I've heard a number of times when people talk about software planning:

"Everyone has a plan until they get punched in the mouth."

- Mike Tyson

A common takeaway folks seem to have from this is that you shouldn't plan or you should put less effort into planning, because the plan will be worthless.

The takeaway I have from this quote, and the reactions folks have to it, is that people are bad at planning. Planning is a skill. There are techniques that work and techniques that don't, and it takes time and practice to get good at it.

A Good Plan Starts with the Worst Case

People often make plans with the implicit assumption that the plan will be executed under 'normal conditions' or, optimistically, under 'good conditions'. This is natural enough, because the act of making a plan is a fun design activity. But it's an exercise in wishful thinking, because invariably conditions will be 'less than ideal', if not downright bad.

If you plan your boxing strategy assuming your opponent is going to do some average hits to you, that's not realistic. They want to hit you harder than you've been hit before. Start with that. Assume I'm going to take the worst hit I've ever taken. What do I do then?

A lot of software planning starts with the ideal end state and tries to work backwards from there. Here is the feature we want. Here is the ideal design. Here is when we want it by. What plan will make that achievable? Then that's broken down into a series of steps, in isolation, assuming the team will be fully dedicated to making that happen.

There are many problems with that. Let's stick with the 'hit in the mouth' vibe though. Bugs get discovered, systems go down, software updates break things, network latency spikes, cybersecurity attacks happen. All kinds of adverse events happen to a software development team. Sometimes they are new things that no one on the team has seen before, with no clear solution. The team gets hit in the mouth harder than they ever have. The pristine development plan gets tossed in the trash, while the team scrambles to deal with unexpected events and still meet the unrealistic deadline for the original plan.

A Good Plan Incorporates the Human Element

The unsaid part of the quote is that when you get punched in the mouth, you forget everything you were intending to do, and switch to survival mode. Humans aren't robots. We don't always operate in the same mental and emotional state.

Sometimes we feel good, and we're carefree, and we can think well and perform well and knock out challenging tasks one after the other. We stop and consider the finer points of an implementation that weren't considered ahead of time, and craft elegant solutions that handle a variety of use cases with a small amount of clear code.

Sometimes we feel like garbage. Sometimes we are overloaded, and we get into survival mode, and we rush through the work just to get it done. We've got programming-words taped together with gum and duct tape, but by golly, it 'does what was asked'. Next task, please.

If you want work to get done on time and high quality, it needs to be planned so that it can be done well on a developer's worst day, because it's that well defined, well understood, and well prepared for.

Realistic Development Planning

A good development plan starts like this. Assume the team is busy, tackling unexpected problems that are stretching them to their mental and emotional limits. We'd like a new feature in the software. How do we interleave small amounts of work around the team's unexpected responsibilities that can get us closer to that new feature? How we take baby steps towards the goal, that a worn out developer can do as a 'cool down' activity after a hard day of digging into a production issue? How do we answer all the unanswered questions we have? How do we position ourselves so that all the supporting pieces we need for the feature are in place, and implementing it is a piece of cake? Small work gets done, because it fits into all the hard stuff that comes up. Big work doesn't. If all the developers look at a development request and say - "That'll take a day" - guess what... it will actually take a day. If all the developers look at a development request and say - "That'll take a few weeks" - guess what... it might take a year, and be low quality.

Discipline is a critical here. If you can't make a plan work in the worst case, then you have to accept that the plan is no good. The goal is too big, or the current state of the project and team is not as far along as it needs to be. We don't understand the problem well enough, or we haven't done the necessary research on possible solutions. Forget what you want to happen, and be realistic about what can happen. Change the focus to position the team for the future. If a feature will take too long, figure out what pieces are missing so that all the developers agree - "That'll take a day". Then work on those small pieces instead.

And remember - Planning is hard. If it were easy, everyone would be doing it well. But anyone can get better at it.