d’bug shares tips, tricks, and advice with Web development professionals

We are going to be building a new Web application at work. I wish I could tell you what it is, but I am sworn to secrecy (legally). It is something none of us have ever created, nothing any of us have ever seen before, and sure to take longer than any of us can estimate. There is a high probability that if you are reading this, that you are in the same situation, or have been in the past. Whenever I find myself facing an estimate of this sort, I tend to follow these seven guidelines.

Do the research

Sales estimates are rarely billable, and almost never rewarded. That is why so many developers get a feel for the basics, and then throw a number at it. If another programmer ends up with a project landed from an estimate like this, then jaws usually drop, and tempers flare. If you are the one to end up with the project, then you have to cover your tracks.

You have to do the research when it comes to estimates. Has another developer completed this task before? Are there unknowns that can become more knowable by talking to sales engineers or the client? Even searching for blog posts and articles detailing projects close to yours will be a benefit. All avenues need to be exhausted.

Deconstruct all large tasks into smaller tasks

It is near impossible to provide an accurate estimate if you are unable to break large tasks into smaller tasks. A blow-by-blow for every fifteen minutes of work is not necessary, but anything more than a day needs some serious thought.

Consider a data reporting dashboard for any number of applications, which includes numerous variables and algorithms. There is the aggregation of that data, the storing of that data, making sense of that data, and making sure the user can make sense of that data. Stating only that it should take 80-120 hours oversimplifies the problem. Without actually prototyping, envision the objects and behaviors that belong to the system and estimate those pieces alone.

Add peripheral distractions

Depending on where you work, some meetings, breaks from the grind, and on-the-spot brainstorming sessions are not billable, and therefore, never make it into the timeline. Although you might consider this padding an estimate, it is surely not. Every client needs to understand that no one comes up with a winning idea on the first day. The evolution of a project has additional costs, and those need to show up in the estimate.

Clients will complain. “I don’t pay you to take bathroom breaks, or drink coffee,” they will say. The answer should be from management, “If you want this project to go as planned, then try not to treat the work like a long day hammering spikes into a railroad track.” You need not bill it as a smoke break, but these peripheral distractions need to be accounted for in some measure.

Freeze the requirements

This one might sound as ridiculous as the last, but it is a necessary evil. Your estimates should only take into account the requirements communicated during the estimating phase. For this to become a reality a team review session facilitated by a project lead is an absolute requirement. Everyone needs to review everyone else’s estimates for flaws or feature discrepancies.

While working as a developer in a previous job, it was well known that some information architects and art directors liked to throw caution to the wind. Delivery of a quality interface always meant introducing new functionality not scoped or requested. During review sessions these features were often identified, and then introduced as upsells. It helped reduce surprises and cost.

Write assumptions liberally

As much as I hate doing it, I am also the king of writing assumptions. This ties closely to freezing requirements, but it is a blanket response to fuzzy details. It is a way of stating, “I think I know what the client wants, but I am going to propose some immediate solutions just in case.” If the team can agree that is the best approach, then it can help eliminate discrepancies between what was estimated, and what was delivered. A review session will help to vet these assumptions.

Add five percent for system failure

Now this is what is known as padding. Some companies will introduce three to five percent into the estimate to increase profitability, but the addition should be a fail-safe for system failure. I do not mean a failure of ideals, but I mean an actual system failure like a down hosting provider, a corrupted database, or a computer crash.

The best line of defense is a documented backup plan, and in-place data recovery procedures, which of course should all be estimated. However, it could be that your company has crisis management under control without the need for padding. This could actually reduce estimates, and compliance to specific procedures can help make you a more attractive choice to potential clients.

Leave the up-to-speed time at the door

There is one aspect of programming that some developers are unable to stomach. Learning on the job is not always possible, but bringing that knowledge back to work is almost always necessary. Clients will only carry so much weight when it comes to estimating up-to-speed time. They often look for service providers that have very particular experience. If finding that experience is not possible, then they expect to work with a company that will shoulder some of the cost.

The benefit is that you get the new knowledge, and in exchange they get a discount. The problem is trying to get this up-to-speed time added to the timeline even if it is not in the budget. The majority of developers will see this as an opportunity, but if it becomes a company habit, then it is time to discuss additional compensation with your employer.