The Regenerate Web

There are two unkind words that derive from the farm - manure from a bull (BS), and manure from a horse (HS)?  I have a working assumption around colloquial language that says HS is used to describe something of poor quality, questionable value.  HS ususally is the result of poor workmanship, poor raw materials, poor process, etc.  BS, on the otherhand, is deceptive.  BS is usually used to describe something passing as something else; a deception, an "error" masquerading as truth.  The fable "The Emperor's New Clothes" is a story about BS.  When you call BS, you are saying that you "see" the emperor, and he is naked, and ugly!  

I hereby declare that when it comes to project plans, I strongly prefer HS to BS!!!

I have been going through a major planning exercise with my current team.  I have been using "pure" effort estimates and velocity projections to produce project schedules for a while.  The basic technique is simple, in that you take each milestone, summing up the effort from the deliverables and project velocity in effort/time to create a duration estimate (in weeks).  Then you can lay out the schedule.  Each velocity projection can also be turned into a resource requirement (i.e. I need sufficient resources to deliver 18 effort days of work per week.)

This is the first time that I have been through this exercise with this team, and they have struggled mightily with the concepts around planning.  Here is the list of planning approaches that I have seen this time:

1. kitchen sink plans - containing anything and everything the planner could think of.  
2. template plans - lots of detail, cut and pasted from deliverable to deliverable.  
3. story telling - lots of tasks with no estimates, or with BS estimates.
4. activity based deliverables or tasks, rather than result-based (since I am going to spend time doing it, it must be a task).  

Given that I am laying out the schedule (towards the beginning of the project) - I am not too concerned about detailed tasks.  I want to capture in broad strokes what our deliverables are, and about how much effort is required for each one.  I have learned that planning and software design happen concurrently, not in sequence, and that each one informs the other.  My lead developers, on the other hand, seem to want to lay out tasks in order to get to deliverable estimates.  They are less comfortable with "SWAG" estimates.  They also feel that they are totally "on the hook" for these estimates.  So they use some of the approaches above to justify their estimates.  I really don't care, if I want to argue about estimates, I will argue.  If they can't explain why it takes 12 man days of heads down effort to create a single web form, I will slash their estimate.  Regardless of the shitscreen that they throw up.  

Building software is difficult and complicated, but some things cannot be known ahead of time.  I would rather baseline based on knowing that we don't know everything.  This is what I call HS planning, we know our plan is crap, but we have to start somewhere.  Plans with slack, or place holders to account for areas of risk fall into this category.

BS example:

• Clarify requirements - 2 days
• Complete object model - 2 days
• Code and test object 1 - 2days
• Code and test object 2 - 2 days
• Code and test object 3 - 2 days

The obvious issue here is that until we complete the object model, we don't really know whether we have 1 or 5 objects to code, and whether they all take the same amount of time or whether some are heavy and some are light.

The trouble comes from trying to compensate for the fact that we don't know everything by fabricating plans that have details that appear to justify or rationalize the slack or the size of our estimates around unknowns. This is BS.  It creates tasks that will be replaced later when we know more.  If we have a plan that has the following tasks:

HS example:

• Clarify requirements - 2 days
• Complete object model - 2 days
• Refine project plan - .5 days
• Code and test all modeled objects - 6 days

While that is utter HS, because it does not describe specifically what needs to be done, it is not BS, in that it does not mislead you into thinking that we actually know what to do.  We would never commit the "code and test" task.   At the point where we needed to commit this task, we would already have refined the plan, so the tasks we would be comitting would be the new refined ones, and this HS one would have been replaced  by that time.  

One must recognize that every plan, at the first baseline, has some manure in it, the question we should ask is "what animal did it come from?"  Is it a recognition of unknowns and risks, or a rationalization of our guessing.