Seriously.  Who else dreads giving estimates or quotes for development work?  I know I can’t possibly be alone because new clients always request them.  Anytime I am asked for an estimate, it’s always an exercise in futility.  I’ve been in web development for a long time now, and I can never seem to nail down accurate estimates.  As time has gone on, it’s gotten worse.

Building Experience

I got my start installing osCommerce “contributions” at fixed prices.  It was a pretty simple thing to start out with since the packages always included installation guides.  “Edit [file], add [code] on [line number].”  The popular “contributions” were installed on almost every osCommerce site.  Packages for SEO URLs, additional product images, stock tracking for variations, extra product fields, etc. were always in demand.  As I integrated the same packages over and over, I came up with a list showing how long it took me to do each one.

I always asked new clients if they had a “stock” osCommerce store or one that had been previously altered with pre-packaged add-ons or other custom code.  Of course, when the existing shopping cart code had already been altered, I ran into merge conflicts that had to be resolved.   It was frustrating to spend more time than I anticipated on a job, but those times were when I actually started to learn PHP.¹Figuring out how to condense two disparate lines of code required the knowledge of context.  Following a “do this, do that” document did impart a background of where things were in osC, but it did nothing to teach me the how or why.

Getting back to the topic of estimates, all of the above illustrates that relatively accurate time estimates are achievable for repetitive tasks.  If I’m asked to do something I’ve done before, I can expect to spend roughly the same amount of time on it this time.  The estimate is for a “known quantity” of work in my mind, so there’s little stress when providing these types of quotes.  However, these types of situations aren’t common in my work these days.

Knowns vs. Unknowns

Vastly more common are the unknowns, and this is where my issue with estimates lies.  Let’s say I’m brought in to resolve a bug in an internal system that is completely custom.  Without knowing how the code is arranged or which, if any, underlying platform is being used, how can I even guess as to how long it might take to resolve the bug?  The bug could be in a high-level method that’s easily found by backtracing and outputting variables along the way .  Conversely, the bug could be buried in a third-party API call where the API has no publicly accessible logging.  These two scenarios could vary greatly in terms of time required, but they still have unknowns that can only be realized by working on the code.

In a somewhat better hypothetical situation²Not really.  All of the scenarios I’ve mentioned are based on true stories., the client may use a known platform like Laravel, WordPress, CodeIgniter, etc.  However, the previous developer may not have adhered to common standards and practices when building and maintaining the system.  If that’s the case, it’s unlikely that the client can provide the needed insight for an accurate estimate.

A Guessing Game

In these situations, it really does turn in to a “best guess.”  Don’t get me wrong.  I have a lot of experience to fall back on, but more often than not, that experience tells me to add more and more time to an estimate to account for the unknown.  It does not allow me to hone in on a number of hours in which I already have good confidence.

Needless to say, all of this is pretty obvious to anyone in the service industry.  Unknowns always pop up, and it’s our job to deal with them.  If you’ve provided an estimate of $1000 for a project that you believe will take 10 hours, the client will expect to pay $1000.  If it takes longer than 12 hours, that’s on us.  The client will see overruns as a lack of preparation or an overstating of ability, but it really isn’t a fair judgement.

Each client and project is unique in web development.  If, however, I was an auto mechanic, I could easily and confidently estimate how long it takes to repair a water pump on a 2002 Honda Civic with an automatic transmission.  In fact, mechanics pay for subscriptions to databases that provide estimates for work done on specific vehicles.  Even if they’ve never performed a specific task on a vehicle in the past, they at least have some information on which to base an estimate.  I obviously don’t have access to something like that

“Discovery” Phase

In attempting to be as prepared as possible when going in to a project with a lot of unknowns, I’ve started to include “research” as a line item in quotes of this nature.  Similar to the “discovery” phase in a court trial, doing preliminary scouting of the current code base or back-end system and/or Googling for a few hours to learn about an API I’ve never accessed before performs a couple of functions.  It also gives me some additional time to ask the client more detailed and further flesh out their vision.

The first is that it gives me some extra padding on the overall estimate if I can get through it quickly.³I don’t want to overcharge clients, so I try to keep the “research” time to a minimum as much as possible.  Secondly, it tells the client upfront that there are unknowns and I’m doing my best to account for them.  If I happen to need additional time during a project, the client has already been prepped for the news.  Another, albeit smaller, benefit is that it shows I’m trying to think ahead as much as possible.

Even with the extra time, it still may not be enough.  I mentioned the API scenario earlier as an example.  Having little or no control of a situation like that doesn’t help.  I can’t really control the accuracy of third-party service responses.  If I have to engage the service’s tech support, I have no power to shorten their response time, and I can only hope that I get someone with the right knowledge and access to assist me the first time.⁴I’m also hoping to get someone who is a native English speaker.  Grrrrr.

All of this to say that I get really antsy when it comes to giving estimates, especially for projects that have a few question marks.  Perhaps it’s my over-analytical personality that attempts to envision every possible “gotcha” that might pop up, or maybe it’s because I undervalued my time a little too much in the past.  Clients expect firm estimates from all service-related professionals, but that doesn’t mean I have to enjoy the process.

About David

Web Developer