Wed 5 Mar 2008
As the manager of a development team, software schedules and estimates are frequently on my mind. A couple of my previous blogs covered estimates: The Perfect Estimate and Software Estimates and the Parable of the Cave.
Today, I want to discuss a common problem that occurs after the estimate is delivered. Often, the estimate is considered to be too high and management tells you how long you have to complete the task. Sometimes this is motivated by important business goals. Other times it’s motivated by a manager who wants to look good or has a bonus tied to a delivery date.
Regardless of the reason, when the team is given the new timeframe they have to scramble to meet it. Often, teams cut corners to try to hit what is, otherwise, an impossible deadline. This has happened to me on a couple projects with what I know now as predictable results. To illustrate it, I offer:
The Parable of the Loaf of Bread
In a land far away lived a king who was terribly fond of bread. He ate bread at every meal and would often request it as a snack. One day the king requested some bread, but he was told by the royal baker that they were out. Apparently, one of the apprentice cooks had used all the remaining bread to make croutons.
“Off with his head,” yelled the king, not at all pleased that he couldn’t have some bread. “Now, how long will it take you to get me some bread?”
“Good King,” replied the royal baker, “I can have a nice, hot loaf of bread for you in about 2 and half hours.”
“Two and half hours!?! Not good enough! I want bread sooner. Bring some bread in an hour or you will share the fate of your apprentice.”
The royal baker returned to his kitchen, determined to meet the king’s deadline. But how could he do it? Every good baker knows that it takes 10 minutes to mix the ingredients for the dough, 15 minutes to knead the dough, an hour to let it rise, and then another hour to bake. How could he finish in an hour?
“There’s nothing I can do to mix the ingredients faster,” he thought. “But maybe I can let it rise for a shorter time. And maybe I can bake it quicker if the oven is hotter.”
So he set about to make the loaf of bread, cutting corners wherever possible. He placed the bread in the oven after letting it rise only 20 minutes. He thought to himself that that loaf looked small, but hoped it would come out OK. After 30 minutes he removed the loaf from the oven. The outside was too dark from the higher temperature, but it didn’t look burned. Maybe this will be fine.
The royal baker rushed the hot loaf up to the king without a minute to spare. The king sliced open the bread to find that the crust was way too hard and the inside too dense and not at all cooked.
Thoroughly displeased, the king looked at the royal baker and asked, “What is this? This is not a decent loaf of bread!”
The royal baker replied, “Good King, I did my best to bring you a loaf of bread in the time you allotted, but this is the best that could be done.”
“How long will it take,” inquired the king, “to bring me a decent loaf of bread?”
The baker thought for a moment, but there is nothing he can do to shorten the amount of time. “I can have a nice loaf of bread for you in about two and a half hours,” he replied.
“Two and a half hours!?!” yelled the king. “I already gave you an hour. So bring me some bread in an hour and a half or I’ll cut your head off.”
The baker returned to his kitchen, highly motivated to give the king what he wanted. Try as he might, he could think of no way to bake a perfect loaf in the amount of time given. So, he took the uncooked center from the first loaf and added in a bit more dough. He didn’t have time to let it fully rise and he had to cook it for less time than it should, but it was the only way he could produce a loaf in the allotted time.
At the end of the hour and a half, the baker returned to the king with the new loaf of bread. Again, it was overly done on the outside. The inside was a mixture of dry, dense dough and underdone dough.
The king was furious and called the guards to have the baker executed. He had the assistant baker brought before him and asked him how long it would take to bake a nice loaf of bread. The assistant baker, clearly unnerved by the fate of the former head, now headless, baker responded, “Your Majesty, I am aware of your desire for some nice bread. However, there is nothing I can do to speed the process and produce a loaf that is worthy of your Highness. I can bring you a nice loaf of bread in about two and a half hours, but I could make you some delicious rolls in about half that time.”
The king mulled it over for a few moments and said, “Very good. Some rolls would be nice.”
In software development, this cycle is all too common. A deadline looms and we eliminate steps that we know are essential to producing quality code. We throw out unit testing or greatly reduce the number of tests produced. We eliminate design and code reviews so we can spend more time writing code. I’ve even seen projects curtail analysis and design thinking they can adapt as they figure out the fine points later.
The problem with this is that cutting corners produces poor software, often with a high rate of defects or a design that can’t be extended or modified to meet changing requirements. As the code base grows and has more of this low-quality code, every subsequent unit of development takes longer than the ones before it. Rather than providing the basis to speed subsequent development, it slows it down as you are forced to trace problems and limitations in work that was previously “done”.
It’s hard to get non-developers to understand the impact of using poorly written code. But it is as clear and obvious to developers as attempting to use a half-backed loaf of bread to jump-start the creation of a new loaf. So it’s important to push back and try to educate your partners about what they are asking you to do.
Explain the risks involved and why essential steps can’t be skipped. I’m not saying that you should be a purist. Be pragmatic and willing to bend. When your back is against the wall, you should look for ways to perform steps, like unit testing, as quickly and efficiently as possible. You may find that the business need warrants the risk of skipping unit testing on infrequently used or less complex code paths.
Try to get them to reduce the scope of what is planned, just as in the parable when the assistant baker offered rolls instead of a loaf of bread. Cutting features is the surest way to shorten a schedule. Even if you don’t get permission to drop features, work on the code in an iterative and incremental manner. Get the essential functionality finished before adding bells and whistles, even if you’re told you can’t ship without them. When they’re given the option of shipping without them or shipping nothing, you’d be surprised how often they are willing to leave them off.
Hopefully, your project is a team effort and not a monarchy. Just as there are development considerations that they may not understand, there may be business considerations that you don’t understand. Work together to define an acceptable level of risk and then perform your development accordingly.