Plan Intentionally

I previously wrote about being intentional, but focused mostly on intentionality in execution.  Being intentional is also important in planning.  When planning a new product or the implementation of a feature, it is important to explicitly consider all aspects.  It can be a temptation to move past the hard problems too quickly.  “We’ll get back to that later.”  Doing this can be disastrous.  It is important to note that the decision on how to solve a hard problem *will* be made.  It can be made up front in a thoughtful way, or it can be made on the fly at a later date, but it will be made.  Putting off the hard decisions merely makes it more likely that they will be made on the fly.

This advice may seem obvious, but people don’t always follow it.  For critical-path decisions, people know better than to leave them for later.  It is the difficult peripheral issues that are sometimes left undecided.  The boundaries between two modules might be such a place.  The decisions on how to implement the module will certainly be decided, but might the way it is extended by or interacts with others be left for later? 

I recall working on a feature for WindowsMe (this feature never shipped) which allowed video playback to be conditioned on some criteria.  Perhaps the parental levels were too high or the rights were not present to play a piece of video.  In that case, this feature would recognize this fact and stop playback.  The developer responsible for this feature had created a complex infrastructure with plug-in providers and a great signaling mechanism.  I was brought in to test the project late and took over from someone else.  After looking at the documentation and playing around with it for a bit, I thought I understood what was going on, but there was one part that confused me.  I went to the developer and asked him what happened when he sent the message that playback should stop.  Who listened to this event?  His response was that he didn’t know.  This hadn’t been specified.  Stop the presses!  Here we had a conditional playback system that was just shouting at the wind, hoping someone would hear it and do the right thing.  The developer of this system as well as the developer of the playback pipeline had both written fine pieces of software, but one detail hadn’t been intentionally planned and the end to end feature would not work.  Admittedly this is an extreme case, but similar things happen on a less obvious scale if people are not careful to plan intentionally.

It isn’t always that the decisions are considered unimportant.  It is that time runs out.  When a hard decision is bypassed because it takes too long to decide, the chances of circling back to it before time pressure says coding has to start is high.  It is better to take the time to make the hard decision up front and leave the easier decisions to be made on the fly.  Acknowledge that there may not be enough time to do all the planning desired.  There never is.  Then decide on the most critical items first.  Be intentional about what is and is not going to get planned.  This way the unplanned items end up being those that are most conducive to being planned on the fly.

In short: Tackle the hard issues early.  If you wait, they will be decided in a default/easy way.  If the issue was hard to decide up front, it will never be decided well in the midst of coding.