Time Tables versus Mile Stones

It's Saturday morning and you are going fishing. You need to catch twenty blue gill because you have invited friends over for dinner for some fresh fish, home fries, coleslaw, and hush puppies.

You need to have the fish caught by 4:30 p.m. and cleaned by 5:00 p.m. in order to have them hot out of the skillet for when the guests arrive.

What time should you go to the lake and start fishing?
What time is the latest that you could possibly go and start fishing?

Those questions are just to get you to thinking.

I live in the United States of America. Currently my country is involved in what is commonly referred to as a war against terror on two fronts. The fronts are Iraq and Afghanistan. I am not giving my opinion on any aspect of these military actions other than the issue of time tables.

Currently there are those who desire a time table for when military action will be completed in Iraq.

Too often time tables are the results of "pure management". What I mean is that those that are not actually doing the action but have some relationship with the outcome try to manage by arbitrary dictate of schedule. Managers may try to time-box everything into a neat package. Managers like neat.

(This will be tied to Software Development. I hope you can wait.)

Let's go back to the fishing analogy.

Let's suppose you allow thirty minutes to catch the twenty blue gill. I personally have caught that many fish in that time, for real. And there have been days when I have caught one or two in thirty minutes.

Let's suppose you have been fishing for fifteen minutes and you only have four fish. You may inform the fish that you are on a time table if you like, but I think it will not entice them to bite.

Obviously you can't make fish bite and you can't predict how long it will take to catch twenty fish. Fish have a mind of their own and are motivated to take bait by many factors which you can not control.

My advice to you is to go fishing as early as you possibly can and have a couple of ponds or lakes you can visit. Also, invite your friends over for some fresh fish or for brats, depending on the outcome of the fishing trip.

Now I will draw this closer to programming by returning to the Iraq time table. It is closer to programming because people are involved, not fish.

When dealing with people, time tables are used to focus the people on the tasks at hand. It is supposed that people may not work as hard as possible unless there is a tight schedule and management pressure. Often rewards for early delivery or punishment for late delivery are used as an added motivator.

It could be argued that in Iraq there are those that would prefer a U.S. military presence for a very long time. Maybe the Iraqi government prefers having the U.S. risk military personnel instead of risking Iraqi citizens. Maybe the Iraqi government prefers having the U.S. military infrastructure at their disposal because it is cheaper than developing their own. Maybe there are military contractors that want to continue involvement because it is lucrative for them. Which ever reasons exist it seems to show that there are conflicting interests and no common goal.

Just as you can not clean a fish until it is caught and you can not fry the fish until it is cleaned you can not expect Iraqi security forces to take control until there are sufficient members of the Iraqi security force. At least with the fish story if you don't catch the fish in the time allotted you have told your guests they may have to eat brats instead. I do not know of any alternatives in the Iraq situation. Mile stones have to be reached before the next step can be taken.

Another aspect of management setting aggressive time tables is that it can be inferred that management considers the work force lazy and not working as hard as it can all of the time. In the situation with Iraq it may be inferred that the military personnel are not doing their best job. This inference can be very upsetting because military personnel are putting their life on the line and it is insulting to think that the managers feel they are not doing their best job.

For some it is considered failure to move on to the next time boxed item before the previous is finished. Continuing to move forward without finishing items is building failure upon failure. That is why you will hear it said that "failure is not an option". A series of failures or incomplete objectives create instability and invite opportunities for disaster. For military actions such behavior would seem total foolishness and would risk further loss of life and possible defeat. That may be why time tables are associated to defeat.

If you are building a house and you do not complete the foundation just because the time for completing the foundation has passed an you move on to installing the walls it would seem foolish to most everyone. If you are fishing you do not go to the cutting board and get out your filleting knife just because it is time to start cleaning fish if you don't have any fish to clean.

Software development, fortunately, is not as rigid as building a house or managing a war. A software product may have many features. However, not all of those features are needed for a first release of the product. In software it is actually preferred to release enough features to place the product into the market such that the product can gain traction, build a user base, and start a revenue stream. After the first release feed back is used to select a few more features and a new version of the product is released. This continues over and over again for as long as the product is marketable and viable.

Software can combine time tables with mile stones.

Suppose we have product with many features defined. The market seems to indicate that a release in twelve months would be optimal. The features are prioritized and an estimate on the time to deliver each feature is made. Features are organized by dependency so that if feature D is wanted in the product release it is understood that features A, B, and C must be developed first. (Notice that to get to D, you must pass milestones A, B, and C.)

After the dependencies and estimates are in place a sub set of the total feature set is selected and this will be the goal for the twelve month time table. (I just realized that I am imagining a desktop application so delivery of the product is more complex than a Web app that could be rolled out incrementally.)

The product now has a feature set definition. At this point each feature, in order of dependency, can be time boxed (a time box is a start date and and end date) and the features can be organized and assigned. This is effectively serializing the feature set.

As each feature is delivered (this implies that it really does work) the product's release schedule can be monitored to give an idea if the product will ship on the desired date.

If the feature set of the product is a bare minimum and can not be reduced further then the product can not ship until every feature is completed. If features take longer than expected then the ship date will have to slip. There is no alternative. You can not alter time. Therefore mile stones actually trump time tables. Delivery is an end, time tables are a means of estimation. Do not confuse the means with the ends.

Now, let's imagine managers, pure managers, trying to shorten the development time for the product OR trying to include more features in the twelve month period. When I say "pure manager" I mean they can not develop code so in other words they can not do anything to help get the code finished any sooner. They can't lend a hand.

If the managers will not increase the number of developers and re-assign existing tasks amongst the work force then it seems impossible to get more done in less amount of time.

For management to change the dates because they feel the work force is not working at full capacity can infer that management feels the workers are lazy. That is insulting to the work force. Maybe management feels the workers have padded the time estimates. The workers will recognize this and infer that management feels that they are dishonest and lazy. The workers morale may drop and if that happens then there will be side effects.

Here is something I want you to consider.

If you have hired the brightest and best developers, and if they are completely honest and ethical, and if they never get sick or have any personal issues or crisis, and if they are the very best at software architecture, then how ever long it takes them to develop a software product is the shortest amount of time that it could possibly be done in and no manner of process management would have decreased the time to delivery.

Now, given those brilliant developers described above, if there are other tasks besides just the development tasks that need to be organized then it is prudent to add another task to the developers (which will take time and thus push the finish time out further) to estimate feature set release dates so that marketing can queue their tasks, documentation can queue their tasks, etc. By organizing other tasks to be performed in parallel you can shorten the overall time for the complete release and delivery of the product.

As each milestone is reach (each feature is finished) the time tables can be readjusted and parallel tasks can be rescheduled.

The software will not be done until the last feature is delivered and it will take how ever long it takes. Mile stones have power over time tables. They always will, if you expect to finish something.

I hope you understand my analogy with fishing, with the very difficult situation of the Iraq war, and with house building.

Your comments are welcome.