"This website is quite simple. All you need to do is complete X, Y, Z. You seem to be very skilled technically, so I believe you won't need to spend much time to get it built."

I receive emails like this from time to time. Almost all the people who write these emails are either non-technical or working on their first product. At first, when I heard people say things like this, I was always very annoyed. Who were they to argue with about the time software development takes? But later I realized that even I myself am at a loss when predicting how much development time my own projects will take. If I can't even do it myself, why should I be annoyed with those people?

What really depresses me is not the error in their estimates. The problem is that they actually believe they can make a correct estimate. As developers, we often find that when it comes to software development, an outsider will naturally estimate complex things as being very simple.

This is not an excuse for our anger. But it does raise another interesting question: why does our innate ability to predict complexity fail when it comes to programming problems?

To answer this question, let's look at how our brains estimate things. Some things are easy for even inexperienced people to estimate correctly, but other things are not.

Let's think about watching someone play the guitar. Even if you have never played the guitar, after watching a guitar performance of "Mary Had a Little Lamb," you can roughly guess that it is simple and that a person doesn't need very advanced skill to play it. Likewise, after watching someone play Pachelbel's Canon in D major, you can easily infer that it is complex and requires a long time of practice to play.

Why can we quickly and accurately estimate the complexity of these two pieces? It is related to the methods we use to judge whether something is simple or complex. Our brains have some ready-made patterns for accomplishing these tasks, and the first is based on speed. In this case, the brain identifies what is being played per second. Based on how much is played per second, we can easily have an intuitive judgment of the piece's complexity. Because playing a song on the guitar is a physical process, a sensory activity, our brains can easily infer speed based on this, and then convert it into complexity.

We also have another innate basis for estimation: volume. Think about comparing a tent with an apartment building. Even if a person has never studied architecture, they can tell you that designing and building a tent is usually simpler than designing and building an apartment building. Why? Because we innately use physical volume as an indicator of a thing's complexity.

Of course, these two kinds of logical analysis are not always 100% effective. But in most cases, this is how people do it, and with great success. In most situations, when we evaluate physical processes, our brains make effective associations with physical objects, without needing to rely on previous experience.

Now let's talk about software. When a non-technical person tries to estimate software development time, there are two very basic intuitive indicators assisting them: complexity measured by volume and complexity measured by speed. But they don't realize that software is not what they imagine it to be. Software is essentially not a tangible substance. It has no volume or speed. Its tiny components may occasionally flash across the computer screen. Because of this, when faced with developing a web application (or any type of software), our basic intuitive senses fail.

The first point, speed, is obviously completely impossible for an outsider to use to evaluate software. So naturally, they tend to use the volume indicator to evaluate. Either based on the number of pages in the specification document, or based on the number of use cases or features of the software.

Sometimes this evaluation method does work! When faced with a static website with no special design requirements, an outsider can easily estimate the development time this way. But usually, for software development, volume cannot truly and effectively reflect complexity.

Unfortunately, the only effective way to estimate software complexity is based on experience. And it doesn't even always work well. As a programmer, I know that based on similar features I have developed before, I can estimate how much development time each of the current features will take. Then I add up the total time, and that gives me a rough estimate of how long the entire project will take. However, in reality, every project encounters two or three bottlenecks during development. These bottlenecks can recklessly consume a programmer's large amounts of time, and you cannot foresee them before encountering them. They can hold up the entire project, delaying it by weeks or even months.

These are things that inexperienced people will not understand when estimating complexity. They don't understand why methods that work well for other things don't work when applied to software development. So, the next time you hear someone say "I think you can develop it in a few days," no matter who says it, don't get frustrated. Take a deep breath, show them the address of this article, and go back to whatever you were doing.

[Original English text:I'm Sure It Will Only Take You A Few Days To Code ]