I’m Sure It Will Only Take You A Few Days To Code

from:http://danshipper.com/non-technical-people-cant-estimate-developmen

“So the site’s pretty simple, all it needs to do is X, Y and Z. You seem like a good programmer so I’m sure it will only take you a few days to put it together.”

I get emails like this from time to time. The people that write them are almost invariably not technical and working on their first product. At first I got pretty annoyed when people talked like this. Who are they to go around estimating development times? But then I realized, even I am terrible at estimating how longmy own projects are going to take. How can I get mad at them if I can’t do it either?

The real reason I’m annoyed is not that their estimate is wrong. It’s that they assume that they can even make an estimate. That’s because as developers we unconsciously realize that the way a layperson naturally estimates complexity breaks down when it comes to software.

That’s not an excuse for being annoyed. But it brings up another more interesting question: why does the way we naturally measure complexity stop working when we apply it to programming?

To answer this question let’s think about how our brains estimate things. There are some things that are easy for someone with no experience to estimate and some things that aren’t.

Think about watching someone play guitar. Even if you’ve never played guitar you can probably infer from watching a performance of Mary Had a Little Lamb that it’s simple and that the person playing it does not need a great deal of skill to do so. It’s also pretty easy to watch someone play Pachabel’s Canon in D and infer that it is complex and would take a long time to learn how to play.

Why are we good at instantly estimating the complexity of these two songs? It’s because of the way we judge whether something is difficult or easy. Our brains have a few built in tools to do that and the first one is speed. In this case, it’s notes played per second. Notes played per second gives us a really easy, natural heuristic to estimate song difficulty. And because playing a song on the guitar is a physical, sensory activity it’s simple for our brains to measure speed and convert it into complexity.

We also have another natural heuristic: size. Think about a tent versus a mansion. Even someone who has never been to architecture school can tell you that in general it’s a lot easier to design and construct a tent than it is to design and construct a mansion. Why? Because we naturally use physical size as an analog for complexity.

Obviously neither of these are reliable 100% all of the time, but in most cases in life it gets the job done. That’s because in most cases we’re estimating something physical that our brains can relate to efficiently and without prior experience.

Now let’s talk about software. When a non-technical person attempts to estimate software development time they come armed with their two basic heuristics: complexity based on size and complexity based on speed. But what they don’t realize is that software is different. Software is by nature not physical. It exists in the ether. A tiny portion of it shows up on our computer screens from time to time. Because of this when it comes to building web apps (or any type of software for that matter) our basic heuristics break down.

The first one, speed, is essentially impossible to estimate for the layperson offhand. So the natural heuristic they tend to use is size. Some go with number of pages, some go with number of actions or number of features.

Sometimes this actually works! If you’re talking about a static site with a bland design it can be very easy to estimate development time for the layperson. But in general size does not translate reliably into complexity when it comes to software.

Unfortunately, the only heuristic that works when it comes to software complexity isexperience. And even that doesn’t work all the time. As a programmer I know I can use my prior experience building similar things to estimate how long each feature will take to implement. Then I add all that up and come up with a rough estimate of when I’ll be done with the project. But the fact of the matter is that in every project there are two or three bottlenecks that crop up during development. These bottlenecks suck up an inordinate amount of programmer time that can’t be reliably predicted beforehand. And so it throws your entire project off schedule by weeks or months.

That’s what someone without experience misses when they try to estimate complexity. They don’t realize that what works in almost any other situation, doesn’t work at all when it comes to software. And so next time you hear “I’m sure this will only take you a few days to code” try not to be annoyed with whoever said it. Just take a deep breath, link them to this post and go on with your day.

If you liked this post you should probably follow me on Twitter. Or check out my startup Airtime for Email. We help you market your products with your email signature.