A great thinker once said:
Time is money.
When you start writing code for a living you’ll soon find out how true this statement actually is and unless you have a client who’s after perfection and willing to pay you by the hour for achieving it, you better be damn sure that your estimates are right.
I run a small web development business and in my line of work making accurate estimates is probably the most difficult part about my job. In essence, making estimates is a catch 22. The more time I invest in making an estimate, the more accurate that estimate will be, however, I do not get paid to make estimates. I.e, most of my clients will not pay me for making accurate estimates. This leaves me with the only viable option I have: to guess.
Of course, a guessed estimate isn’t just a random number picked out of thin air. It’s based on years and years of experience. What the good ‘ol gut is telling me.
One important aspect of experience is that when experience increases, the quality of the work also increases accordingly. This means that at some point it becomes difficult to do a mediocre job. Your experience has a direct effect on the quality of the work you deliver. E.g. young and inexperienced programmers are often not so much aware of all the things that can go wrong with the code they write. They mostly focus on the path of least resistance without realising the various “edge cases” such as stuff that could break or external dependencies that can stop working.
So, we can say that experience has a direct effect on the quality of work you deliver and therefore experience also has a direct effect on the estimates you make. In other words, someone with more experience will make different estimates than someone with less experience. Sounds reasonable, right?
Most of my clients intuitively think that because someone has more experience they will work more efficient and that therefore the estimates should be lower. However, this is a fallacy. We all know that delivering high quality work takes more time. I.e. craftsmanship.
So, what does this have to do with the Scale of Perfection? Let’s look at a simple graph:
This graph tries to demonstrate that the Perceived Quality decreases even though the Effort continues.
It’s often very difficult to explain to my clients why a certain job takes a certain amount of time and therefore has a certain associated cost. At the start of a project the Perceived Quality increases rapidly because you go from nothing to something in a short space of time.
Clients like this. They can see progress. However, when work moves behind the scenes and aren’t directly visible to the end user it becomes more difficult for my clients to evaluate progress and justify the cost. To them it might seem that nothing has happened for a week because they don’t “see” any difference and probably ask themselves; “What’s this guy doing, what I’m I paying him for?”. This is what I mean with Perceived Quality.
Note that the Perceived Quality is not the same as the Actual Quality. While the Effort continues, the Actual Quality keeps increasing. E.g. does your client see the value in implementing solid error handling? They might not at first until something goes wrong and when it does they will come back to you and ask you why it’s not working. You might rightfully say that this should be defined in a scope of work or a requirements document. This true. However, my clients are usually not in the business of software. They simply want a website or application that works and a scope or work and requirements document is usually not something they have a direct interest in.
Let’s look at another graph:
In the graph above, the red dot represents an unfinished product. The green dot represents a mediocre but supposedly finished product and the blue dot represents a finished product with a solid layer of polish.
Inexperienced developers will be happy to call a project finished at the green dot. The work is perceived to be finished and all functionality appears to be working. However, after a week or two orders have stopped coming in. After investigation the seems that there was a problem sending out emails because the hosting company changed something in the configuration of the web server. It was only because the client stopped receiving order emails and tried to submit a dummy order that he noticed the order wasn’t arriving. The inexperienced developer didn’t built in any error handling when sending out an email. When emails couldn’t be send out, the error message simply disappeared into the void. It’s unknown how many orders the client lost and what revenue the client missed out on.
The inexperienced developer simply wasn’t aware of things that could go wrong and didn’t cater for it. He certainly didn’t make developing error handling part of his estimate and was therefore cheaper when the client received his quote for the costs of the project.
Would this client have been better of in hiring a more experienced developer? A developer that would have taken notice of the things that could go wrong? A developer that probably would have been more expensive? The client would definitely have received a different estimate and very likely had to pay more to have his website build by a more experienced developer. However, the likelihood that this client would have had problems with his website would definitely have been less and the chance on losing out on revenue very slim.
Perceived Quality is a real thing and unfortunately it’s not always easy to explain why something is of better quality because it appears to “just” work. We only kick and scream at things when they’re broken and don’t coincide with our expectations. The Scale of Perfection is very much part of making correct estimates and being aware of it might make you look at you own estimates in a different way.