Customers are carpenters

This is a follow-up on my previous post Developers are not carpenters. Where I wrote about that building a house is not the same as creating (or building) software.

But if I where to build a house, and hired a carpenter (among many other craftsmen) I would know approximately how long it would take and how much it would cost me. And even though I hired someone to build me the house I would be very interested in the progress and what’s going on and problems etc.

Even if I was to buy a pet (my alternative metaphor) I know how much different pets costs and what they require.

But, most customers don’t really know how much software costs and how long it takes to build it. And, in particular, they are not really interested in the progress when building it.

Why is that? After reading a post by Scott Hanselman, Please Learn to Think about Abstractions, it got me thinking…

The reason I would be so interested in the process of building my house (and I approximately know how much it costs and how long it takes) is because I know quite a bit about building houses! I also know some about pets. But most customers know nothing about building software. The same would probably be true for me if I knew nothing at all about building a house. I would probably accept any price the builder said and probably accept anything he/she says about the time it would take.

I think all customers (that are responsible for the applications in the company) should take a beginners course in software development. If they knew more about programming I believe that better software will be built for them. Just as I will get a more suitable, better, house built for me because I know some about building houses.

And I think most customers is like me – they know how to build a house. But they don’t know how to build software. And that’s why they are sometimes frustrated at us when we ask them a lot of “stupid” questions about building their software.

But do we developers want our customers to know about programming? I hope we do. A couple a months ago we rebuilt our bathroom. We hired some craftsmen to do the job. I was very interested in the progress and followed it in detail and almost every day gave my input and had a discussion with the craftsmen. And when it was finished they talked to me and really emphasized how much they appreciated my participation. They thought everything went very smoothly and was to the better. Both for them and for me.

Developers are not carpenters

At least not figurally speaking :-)

I spoke to a colleague the other day. He had just had a meeting with a (potentially new) customer. This customer had had some bad experiences from previous suppliers. The customer then said: “If I want to build a house. Don’t you know how much it will cost me and how long it will take to build it?” And my colleague tried to answer: “But what kind of house?” “You know, a standard house”. My colleague tried his best “But that still depends, where do you want to place e.g. the kitchen and how do you want it to look like and design it etc. etc.” But the reply still was kind of “As a carpenter, you should know”.

But the metaphor is far from complete. Creating software is not building a house! Software has a soul, a heart, a life. It needs to live, grow up, mature, be fed, be nursed. And who will do that? Both the customer and the developers! And I think that it has been their main problem all the time; as a customer, the more involved in the development you are the better development it will be.

So next time. Reply with “How much is a pet? And how long will it take to breed it?” And also, you just don’t buy a pet and think it will take care of it self and don’t need any attention (the whole point of having a pet at all). The metaphor is just as good (or bad).

 

…”What kind of pet?” “A standard pet?”

My estimates are too optimistic

First of all, I’m not talking about story points here. As a consultant, as I am, most customers don’t care about story points. They care about –What will it cost? and the answer depends on how many hours I, or my team, will spend (don’t tell me about fixed price! I don’t want to here about it!). Story points may solve a lot of problems, but it requires the customer to be accustomed with it (and perhaps use agile methods already). So, still, very often I estimate in hours. Usually for rather “small” improvements/features/changes.

But almost all the time my estimates are too optimistic. And it doesn’t help anyone. Especially not me! So, why? I think it’s because I want to give the impression that it isn’t such a big effort so they will make an order. Or I want to give them the most optimistic estimate for being… optimistic! Or perhaps they think I’m a crappy developer who requires all that time for such a “simple” change/feature. Honestly, I don’t really know…

But, I’ve started to use a simple test to see if my estimates are too optimistic. Very unscientific, but it has never stopped me before, so why should it now :-)? Something like this:

If I estimate a new feature - or anything - to, let’s say, 20 hours. Then I question myself (in front of the customer or not, doesn’t matter): is it just as likely to take 10 hours as 30 hours (±10 hours from my estimate)? -No! 10 hours is not likely at all, even if things runs as smoothly as it could never go (has never happened yet, but I never loose hope…)! But 30 hours is not unlikely at all (if something unexpected happens, and it usually does). Not to mention 5 hours compared to 35 hours (±15); 5 hours is ridiculous, 35 is not likely – but not ridiculous! 0 hours is impossible, but 40 is not (okay, this has to be reasonable; 0 hours is always impossible and 100 hours probably not, but all estimates should therefor not be 50 hours). And all of this is my signal that my estimate is too optimistic.
Then I have to adjust my estimate until the min value is just as likely (or ridiculous) as the max value. Is 15 hours as likely as 35? Yes. Is 10 hours as likely as 40? No. Okay, so maybe I will settle at 30 hours (or something in between, like 28, but I keep things simple here)? 10 hours is as likely as 50 hours (50 hours should not happen). And 20 hours as likely as 40. But wait! 20 hours was my initial feeling! Is that as likely as 40 all of a sudden? Yes, I would say it probably is. In the end, it may take 20 hours after all (my initial feeling was correct) and then I think all I have is a happy customer (because I said 30)! I would definitely have an unhappy customer if I say 20 and it takes 40, compared to that it takes 40 and I said 30 and so on... And to be honest, if you have ever made an estimate that ended up being correct (or very close, yes it has happened) it was an estimate that had some “air” in it – right?

Of course, I could give the customer a min value and a max value. But most customers don’t want it or don’t like it.