One of my favorite online comics, CommitStrip, published this brilliant comic that made me laugh and almost cry simultaneously since I've been caught in this trap many, many times before:
I'm pretty sure that just about every single developer who has worked any amount of time in software development has gone through this at one point or another. I've even worked with some who seem to make this a weekly routine. It's a well-known fact that software developers are not good estimators. We tend to fall into one of two groups - we either underestimate by a lot (just like the developer in this comic strip) or we overestimate by a lot (usually just to compensate for our poor estimation skills). The key work here is a lot.
It's not really anyone's fault that this sort of thing happens. Software development is full of unknowns, no matter how much experience you have, or how many times you've done something similar. All it takes is a single unexpected thing to pop up to wreak all sorts of havok in even the best of plans. Worst of all, these tiny unknowns can lead us through a rabbit hole that will leave us like the poor developer in the comic strip (or rocking back and forth under the desk while clutching my knees - not that I would know about that...). My favorite Quora response of all time can explain this a lot better than I can.
As a freelancer / consultant, one of the first questions I get from potential clients is "How long will this task take?", especially when you're doing hourly billing. It's a fair question to ask. It's also a nerve-wracking question to ask sometimes. I have noticed myself often underestimating with these questions because I feel that if I give the higher end of my estimates, the client will think I'm exaggerating just to get paid more. This might not be true, but that's the mentality I've gotten when giving estimates for work where I'll be paid by the hour.
As I've gotten more sales conversations and getting a better feel on the type of projects I'm being offered, I've been getting better at knowing what types of questions to ask before offering estimates. Here are some of the things I've been doing when talking with prospective clients who have existing applications that I need to jump in to:
Show me the code!
When I began talking with prospective clients, I would offer estimates based on my experience with certain things. With Ruby on Rails applications (and web development in general) there are not too many unique things to do. The majority of it boils down to putting things in a database or displaying them somewhere in a web browser. There's not a lot of unique work in the backend for these types of projects, so I would just estimate how much that has taken me in the past. But that was a horrible way of estimating - you never know what's lying underneath the surface.
As an example, a few months ago I was contacted by a client who initially wanted me to fix a bug on their site. He shared his screen with me on Skype and went through the pages to reproduce the bug and show me what the expected output was. After seeing the bug, I said "sure, that will probably take 1-2 hours to fix". It probably would have taken that long, except when I was given access to their code repository, I realized the function that was causing the bug was inside an 800-line Javascript function inside a 5000-line file. Talk about needles in a haystack. I spent those first two hours just trying to make heads or tails of it all, with zero progress.
Now, whenever someone asks me for time estimates, the first thing I ask for is access to their code so I can assess properly. Some clients balk at this, unfortunately, since they don't want anyone who they haven't hired looking at their super-secret code (which is really not that secret unless you have some patented technology there). But this is the only way I can provide a fair estimate, so this is a requirement for me now going forward.
Not technical? Ask the current / previous developer
Most of the prospective clients who come my way are looking to hire someone because they don't have enough technical help to get their site functioning. This is where asking to see the existing code comes in handy, since they won't be able to answer questions themselves. But something I'm also doing is talking with any existing or previous developers who have worked on this project.
Developers, for the most part, are pretty open when speaking with other developers about a project. They'll tell you plenty about the project you're working on since they've spent so much time on it before. I've gotten a lot of answers to questions I haven't even thought of when asking someone to tell me about the 'gotchas' about a specific project.
For example, in one project I worked on, I was supposed to deploy the fixes to their servers when done with a bug fix on a Rails application. I assumed that they had some tool like Capistrano all set up, so I didn't take the deployment time into consideration since it's all standard. However, when I spoke with the previous developer, he mentioned that their deployment process was the following:
- SSH into their servers.
- In the code directory, pull the latest changes from their code repository.
- Restart the web server.
- Restart all other services manually.
- Cross your fingers that you didn't screw something up and brought the site down.
Even though this is a highly error-prone process, knowing about it beforehand let me communicate to the client (who was non-technical) that it would take a bit longer than I expected since I had to manage this deployment process.
An added bonus is that most developers are typically the first to let you know how bad something is. In my prior example of the 800-line Javascript method, I spoke with two developers after accepting the gig, and they both spoke really badly about the state of the code and they sounded like they had very little faith that I could do something about it. They were right. I now realize that those types of complaints are a huge red flag that I would have not gotten if I didn't speak to anyone technical involved in the project.
Ask about the past
If the work you're doing is similar to something that has been previously done in the project, ask the client how long it took the last time the work was performed. This is a good indicator about how things can go.
In another example, a former client thought the time I was estimating for a certain task was too high. Since he mentioned that this work had been done in the past, I asked him how long it took the last time. He didn't know off the top of his head, so he said he would look it up and get back to me. A day later, he emailed me saying that the task had taken a previous freelancer twice as long as the time I was estimating. Thankfully it took me just about that time, so it was a better deal for him. Remember, the past is the best predictor of the future.
Of course, these aren't bulletproof. While software development is relatively young, people have been doing this for over 50 years and estimation is still one of those things that, despite good intentions, will continue to be hit and miss. We'll just continue to do our best, and in the meantime I estimate it'll get better soon.