Don't Judge a Book By Its Cover

We teach our children not to judge books by their covers. Literally, when they're young and start picking out books to read themselves, not to do this. A book may not have any eye-catching artwork. It could be worn and tattered. The plot introduction on the back might be unappealing. And so we try to instill in them that before forming an opinion about a book you should dive inside and get to know the full story. As children age, this proverb takes on a broader meaning that we shouldn't make snap judgements about other people. Just because someone has tattoos and piercings it doesn't mean he's a felon. Just because someone is clean cut it doesn't mean he's a nice person or trustworthy.

And so all our lives we're taught not to jump to conclusions. Then we grow up, make a career in software development, and that all goes out the window. "How so?" you ask?

Estimates.

It seems most our work starts with estimates. Someone contacts us wanting a new website. They want to know how long it's going to take and how much it's going to cost. If we told them we'd let them know when we're done, they'd get up and leave immediately, laughing all the way. A conversation is had. Likely several conversations are had. The potential client might even have a pretty detailed outline prepared of what they want. If they have an existing site that they want redeveloped into something befitting 2013, we'll do an thorough analysis of it. Nonetheless, we still have to make a judgement call based on a cursory amount of information.

Is this a bad thing? Nah. I don't think so, and I'll explain why in a second. But, I want you to realize that that is what we do all the time as a matter of practice. Think about it. Turn that over in your mind. Chew on it.

Despite what our parents teach us about making snap judgements regarding books and people, we're actually trained to do that sort of thing all the time. The light just turned yellow - slam on the break or step on the gas? Sweetie-Pie wants to know when dinner will be ready. A guy named Big Precious is selling iPads out of his trunk. We spend hundreds of thousands of dollars on a home and even though we have inspections, you still don't truly know what's hiding behind the walls.

Still chewing? Even though we get a lot of practice at making calls based on the information currently available, isn't it still just a little crazy what we do? Saying this is how long a project will take and this is how much it's going to cost? Software development is some complicated sh!t. Technology is constantly changing. Requirements have ambiguity. There are hundreds of things that can happen to cause the most accurate estimate ever to be completely destroyed. Quoting the wrong numbers can not only spell the end of a business relationship but the end of the company.

I think it's messed up but I realize the client is just mitigating their risk. They don't have unlimited money and they don't have unlimited time. It really isn't unreasonable for them to know how much and how long.

There are many ways we can mitigate our risk too including:

1. Gather as much information as possible
2. Use what you've learned from previous experiences
3. Add in ample wiggle room

The big thing though is to be painfully transparent with the client once you crack that project open and dig in. Let them know your progress. Alert them ASAP when reality isn't matching up with the assumptions initially made. If an unexpected complication pops up, sound the alarm. Let them get their hands on the product early so they're not surprised by anything either. Keeping the client informed gives you leverage to negotiate changes to the schedule and cost. The clients are people too. They know things happen sometimes but they deserve better than to be blindsided.

I'm probably not saying anything new here but I hope that I'm putting our process in a perspective that helps us to use it more effectively and keep from getting burned.