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.

Comments

• Anonymous
  February 15, 2010
  thank you steve your article has teach me a lesson that we must plan before doing something.

• Anonymous
  February 24, 2010
  How true! In earlier days I tried to just kick off and think later, but it's much better to have your plans sorted out before and plan much more focused. Although you have to start some day even if the plan's not perfect yet, otherwise many people wouldn't start ever.

• Anonymous
  February 25, 2010
  "Tackle the hard issues early.  If you wait, they will be decided in a default/easy way ... Some managers feel this is a valid way of making decisions. ;-)

• Anonymous
  March 05, 2010
  I agree with john opinion tackle the hard issue first.

• Anonymous
  March 15, 2010
  I just want to add something to this article opinion.In coding for example we must actually solve the small problems first if not how to make the coding works right?This is my own opinion and correct me if i am wrong.

• Anonymous
  March 15, 2010
  @Zukario - This isn't an issue of small versus big, it is a matter of hard versus simple.  One might also think about it as critical versus non-critical.  If a decision is critical, take the time to make the right decision.  If it is not critical, push that to the end.  If you run out of time to plan, that was the best thing to leave unplanned.