When an Estimate is a Promise
I am having my house painted this week. It really needs it, after 10 years. We waited too long as it is.
I chose the painter based on a conversation with him in which I could see that he took pride in his work and would do a good job. I saw him paint a neighbor’s house and liked his work. I wanted THIS guy to do the work and I haven’t been disappointed. He has caulked things I didn’t even know were there.
Yesterday, he mentioned to my wife that the house is a bit bigger than he originally thought. He has used far more caulk than he thought he would. This makes perfect sense to me because the house is 3 stories and has some odd rooflines that were not accessible during his estimation process.
This morning, armed with my 20 years of software estimation experience, I magnanimously approached Danny (the painter). “In my world, an estimate is an estimate, not a promise,” I said. “Let me know if you need to discuss your original estimate because of learning something new as the job has progressed.”
This is where it gets crazy.
“In my world,” he said, “an estimate is a promise. I am a professional and that means that if I am wrong about my original estimate, I will eat that and learn from it.”
Umm…
Errr….
What the hell, people? Is he right and does this apply to software development?
I assume the base response is that we have more variables to contend with than he does, but is that really true? What are your thoughts?
I think one important difference is that, once Danny accepts a painting job, the size and shape of the house is extremely unlikely to change before he is complete. If you decided to add an extension to your house while he was working and expected him to paint that as well, I bet Danny would have a bit more of an issue with eating the cost difference.
He’s been painting houses for years.
Have you been doing the same work for years? Are you using the same materials, *cough*, aka same technology for years ? If so, then yes! By all means your estimates are promises, because you know how long it takes you code the same thing all over again.
I understand and agree with these comments. I just have this yucky gut feeling that we’re making excuses. It’s probably that fact that Eleanor is making me do a juice cleanse and I am not thinking clearly.
Estimation is not so black and white. There are varying levels of accuracy for an estimation. As the domain in which you are estimating gets more complex the ability to accurately estimate goes down.
Estimate: An approximate calculation or judgment of the value, number, quantity, or extent of something
I think we do make excuses a lot of times. I think that we far too often say to the customer “Why didn’t you tell us this before? Now you have to do a CR and the cost will go up.” In reality, the response should often be a recognition that there was a question that we didn’t ask but we should have, or a question that was asked incorrectly or ineffectively. We should be taking responsibility for those, eating the cost, and doing it better next time.
I think he really means “quote” and not “estimate”. By the definition, estimate is supposed to be approximate. If that’s the case, then yes, his quote should be a promise.
Ah! Good point. The difference between estimate and quote.
Hmm…
I’m with @chrismissal:disqus, it’s a Quote, as far as how software devs bid jobs, I know know quite a few devs (myself included) that do the same thing. For example I bid jobs 2 ways, fixed price for fixed AC or Base price plus additional hours for AC changes. If I do a fixed price and the existing code is crap, well sucks to be me.
You’re both right.
If, halfway through the paint job you: changed your mind about the colors three times (after he’d already painted most of the house); decided you wanted a mural painted on the ceiling line of each room; told him you decided someone else was going to do all the taping and caulking for him because they were a little cheaper and expected him to work around them; and then built another house in your backyard and asked him to paint that too, well, yes.
I think he would charge you more.
Exactly. That’s when it shows your integrity as a contractor. I don’t expect my clients to pay for “my” learning time. Wish my flooring contractor had done that when he “estimated” $1600 and finished with $3400.
This is when your estimation skills become more important then your actual job.
I really don’t get it. The guy did a perfect job, but still has to take the loss.
why?
THAT’s my problem with this situation. The guy is doing a great job, and shouldn’t lose money because he’s doing a good job. I expect him to not cut quality and am willing to pay for that. He doesn’t have to eat it.
IMO, your painter pal has the right approach; one that should prevail in the software field, too. Estimate, execute, document, improve. Yes, it’s likely that software estimation is less concrete than a static house and that your pal proly encounters very little ‘new stuff’ in his history of estimation and uses the pretty much the same tools that were in use generations ago whereas software devs/architects are constantly running into new scenarios, new tools, new hardware, etc.; but “we have computers![grin]”
Anyway, promises in any profession are getting pretty rare. Be happy you found a professional willing to stick by his guns and do great work for you.
Oh, and when he’s done with your house, send him over to my place, eh?
Not the point you’re making but… is he exceptional or am I using bad tradesmen?
Chapter 10 of The Clean Coder by Bob Martin is a great discussion on the subject of estimation. He says there is a difference between a commitment and an estimate. He says make a commitment only when you can absolutely deliver on it, and when making an estimate don’t imply commitment in any way (in other words, choose your words very carefully). His belief is that an estimate should be a distribution and also have some sort of probability percentage built-in to the estimate. It’s an interesting read about being a real professional and not just a hacker and coder; I highly recommend it to anyone involved with our field.
While I agree that we may have used a particular technology for many years, all of our work has not been reduced to reusing the same materials over and over again. We essentially have to make our own paint and caulk in many cases. Because of this it is very difficult to determine the exact amount of time something will take to get done.
How about you both suck it up and split the difference?
Ok Estimate can be a promise if :
– Estimate we provide for (requirement) is not going to change.
– Estimate we provide for (requirement) is similar to kind of work we have done in the past.
Unfortunately neither of those 2 stands in field of Software development. So in reality it can’t be a promise. “Promise” in Software engineering is a mere eye-wash.
Stupid question: What is the AC in “fixed AC” ?
Well said. One of the differences I have seen between junior and senior people is the questions they ask during the pre-story and story definition times. The juniors ask few questions, make many assumptions and start coding. The more experienced ones ask more questions and their questions are better. They also tend to be able to put the assumptions aside. I would assume that mamy painters start out working for someone more experienced. They observe the questions they ask, the things they look for, etc when making an estimate. Also, I bet there are a few junior painters that make assumptions and lose their shirt a few times before they get wise. When it hits your income that directly, you wise up or find another career. Sometimes it feels like salaried people don’t feel the same need to improve in that area as the impact is not that direct. Collaboration on requirements is not a skill easily gained, can be difficult to teach and one that should not be taken lightly.
painting a house is not like programming unless each family member stops him every day to tell him to change the colors of the rooms and the order in which he paints them.
painting a house is not like programming unless each family member stops him every day to tell him to change the colors of the rooms and the order in which he paints them.
Hmm… weird. I have over 20 years experience, and if I ask a lot of questions it still pisses my bosses off mightily. They prefer when I just start working on stuff and patch it up as necessary. In fact, from what I’ve read this is a general feeling – they prefer people who “have initiative” (aka just assume things at the start) instead of those who ask about every little detail before starting to work.
I would say that the main difference between painting houses
and developing software is the fact that the painter doesn’t need to understand
what his clients do for a living. When developing software, you will need to familiarize
yourself (at least to some degree) with the business model of your clients, and
implicitly, with their field of work.
Some people mentioned the importance of asking good
questions right from the start. Well, I have worked for pharmaceutical
companies, banks, stock market companies, environment protection agencies, etc.
and I have realized that the really good questions can only come after you have
at least some basic understanding of how the clients define ‘value’. Nobody can
expect you (as a software developer) to become an expert banker overnight (or
during the analysis phase). Basically, you’ll always have to learn new things.
I believe this is one of the main reasons our estimations are approximations and not
promises.
An interesting dialogue. Did Danny (the painter) not assume risk of his estimate not being accurate when he didn’t measure and inspect the complete (non-changing) structure? I believe in his business it’s reffered to as a quote (a promise).
I wish we (in the SW world) had as accurate requirements as he had. But then we would be in the construction business – not the design business. And it is the design world that software development lives.
We construct our products in a few seconds of compile time. Previous to this 20 second phase, we are in design. And we destroy many many prototypes built to scale each time we compile then test and do it again.
Many SW projects are voyages of discovery. Some are not. Perhaps we lump them all in the same bucket, and there in lies our ambiguous nature of confusions.