Another Two Sides to Estimation
Another Two Sides to Estimation
Join the DZone community and get the full member experience.Join For Free
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
There are many ways to look at the issue of estimation. Everyone in the business of software development has had experience with wanting estimates, being asked for estimates, or both. That experience frames how they look at the issue. A considerable share of those experiences have been painful. I dare say that everyone in the business has had some painful experiences around estimation, and the painful ones seem to stick in our memory more vividly than the benign ones.
What makes these experiences so painful? Again, the causes are legion. One frequent contributor is well illustrated by a story my older brother taught me as a child.
A world-famous bricklayer announced he was ready to put away his trowel and retire. Upon hearing this, a rich man approached him to build a mansion. He could spare not expense and build it any way he wanted. The bricklayer thought this was a wonderful way to retire, with one last crowning masterpiece, and agreed to do the job.
He studied the plans that had already been made, scribbled notes on them, and made some new sketches. He toured the building site, compared it with the surveyor’s plat, and did some calculations. After months of study and consideration, he ordered exactly the number of bricks he needed for this final masterpiece. Within days, the bricks were delivered and he went to work.
Day after day, the bricklayer rose early, worked hard all day, and didn’t stop until the light was starting to fade. He worked alone with his hod carrier, so that no lesser hand would mar this magnificent mansion. Like a mad demon, he turned piles of bricks into walls and turrets, until finally he was done. Done! His perfect masterpiece was done.
He backed away to view the full glory of his work. In doing so, he tripped and stumbled. Getting up, he noticed that what he’d tripped over was a brick.
A brick? A brick! There was a left-over brick. That could only mean one thing. He had made a mistake and left out a brick. The bricklayer worriedly ran around the worksite, checking this place and that, looking for where he might have omitted a brick. Everywhere he looked, he could find nothing amiss.
At last he stood in the middle of the construction, brick in hand, and started to realize what had happened. He had failed in his final project. He had ordered one brick too many. Mortified and furious, with all his might, he threw the brick straight up into the air!
This simple story illustrates so many ways that estimation is misused.
- Estimating a precise value without contingency for unknown surprises
- Judging the estimate by the actuals, as if we should know in advance what we know later
- Judging the work by the correspondence to prior estimation rather than by the outcomes
- Becoming angry when the actuals don’t equal the estimate
Does this remind you of situations where you work? I think we’ve all seen these dysfunctions, even if not to this extreme. Considering such behavior, it’s no wonder that people would like to avoid estimation if they can. Unreasonable expectations of what estimates can do, or what the estimators should do are all-too-common. Such unreasonable expectations often result in developers, or anyone asked for estimates, to dig in their heels and try to avoid providing them.
This reminds me of another story.
A man and his wife found that their lives had grown apart over the many years that they’d been married. Each did the things that interested them, and they did little together. The man thought he would surprise her to bring them back together. Secretly he took flying lessons until he got his pilot’s license. Then he rented a small plane and invited her to go flying with him.
He was delighted that she agreed, but as they were leaving she picked up her cat and brought it along, too. The cat that didn’t like him. He didn’t say anything, and they drove in silence to the airport.
After takeoff, he excitedly pointed out the places they knew. “Look how small and different they look from up here!” She murmured, petting her cat. He looked over and noticed she wasn’t even looking out the window when he pointed. That cat meant more to her than anything he could do. He started to get upset. That cat was his biggest rival. Angrier now, he thought, “That cat is the cause of all our problems!”
With one quick move, he grabbed the cat and threw it out the window. “That solves that problem,” he thought. He smiled and leaned back in his seat. He reached into his pocket for one of his last few Cuban cigars and started to smoke it.
At this moment, his wife started to come out of the shock of seeing her cat thrown out the airplane window. Not knowing any other way to get even, she grabbed his cigar and threw it out the window, too. Now, both of them were angry. Neither looked at the other and they flew back to the airport in silence.
Still not speaking, they climbed down from the plane. Then they stopped, amazed. There, clinging to the bottom of the wing with its claws was the cat. And what do you think was in the cat’s mouth? (hover here for the answer)
This story illustrates why estimates become so painful. It’s not the quality of the estimate that makes it so. It’s the fact that those asking for estimates and those asked for estimates (or provided estimates to which they’re expected to conform) each value different things, and ignore the value that the other prefers. They want to get what they want, and are willing to throw out the window those things that are valuable to others.
The path to less-painful estimates lies not in better ways to estimate, or in eliminating them. It starts with understanding each other, what’s important to us, and what we can accomplish. The problem of painful estimation is not about the estimates. It’s about the people and their relationships.
Published at DZone with permission of George Dinwiddie , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.