"The site is pretty simple, all you have to do is do X, Y, Z. You should look pretty technical, so, I'm sure, you don't need to spend too much time setting it up."
I get emails like this every now and then. The people who write these emails are almost always non-technical people or working on their first product. At first, I was always very annoyed when I heard people say that. Who are they debating the time it takes to develop software? But then I realized that even if I had my own predictions about how much development time my project would take, I couldn't do anything about it. If I can't even do it myself, why should I be angry with those people?
What really frustrates me is not their miscalculation. The problem is that they actually think they can make the right estimate. As developers, we often find that when it comes to software development, a layman will naturally estimate complex things as simple.
This is not an excuse for our anger. But this raises another interesting question: Why does our innate ability to predict complexity fail when we encounter programming problems?
To answer this question, let's take a look at how our brains estimate things. Some things are easy to predict correctly for some inexperienced people, but some things are not.
Let's think about watching a person play the guitar. Even if you've never played the guitar, after watching a guitar performance of "Mary had a Little Lamb" you can probably guess that it's pretty simple, one doesn't need to be too tall technology can perform. Likewise, after watching someone play Pachabel's Canon in D major, it's easy to deduce that it's complicated and takes a lot of practice to play.
Why are we able to quickly and accurately estimate the complexity of these two pieces? This has to do with the methods we use to judge whether something is simple or complex. Our brains have some ready-made patterns for doing these things, the first one being based on speed. In this case, the brain discerns what is being played every second. Based on how many things are played per second, we can easily have an intuitive judgment of the complexity of the piece. Because playing a song on the guitar is a physical process, a sensory activity, it's easy for our brains to infer tempo, which translates into complexity.
We have another natural basis for speculation: volume. Consider comparing a tent to an apartment building. Even if a person has never studied architecture, he can tell you that it is usually easier to design and build a tent than an apartment. Why? Because we are born to use physical volume as an indicator of the complexity of things.
Of course. The two logical analyses mentioned above are not always 100% valid. But for the most part, that's what people do, and it's successful. In most cases, when we evaluate physical processes, our brains make valid associations with physical things without relying on previous experience.
Now let's talk about software. When a non-technical person tries to evaluate software development time, there are two very basic intuitive metrics to assist them: complexity in terms of volume and complexity in terms of speed. But they didn't realize that the software was not what they thought. Software is not inherently tangible. No volume or speed. Its tiny components may flash on the computer screen from time to time. Because of this, our basic intuition fails when faced with developing a web application (or any kind of software).
This first point, speed, is obviously impossible for a layman to use to evaluate software. So naturally, they tend to use volume metrics for evaluation. Either by the number of pages describing the documentation, or by the number of functional use cases or features of the software.
Sometimes, this evaluation tool does work! When faced with a static website, there are no special design requirements, and it is easy for a layman to estimate the development time in this way. However, under normal circumstances, for software development, volume does not truly and effectively reflect complexity.
Unfortunately, the only valid way to guess about software complexity is empirically . And it's not always useful. As a programmer, I know that based on similar features I've developed before, I can estimate how much development time each of these features will take. Then, I add up the total time, which gives the approximate time it will take to complete the entire project. However, in reality, every project encounters two or three bottlenecks in the development process. These bottlenecks can consume a lot of programmer time indiscriminately, and you won't be able to foresee them until you encounter them. They can hold up entire projects, delaying schedules by weeks or even months.
These are things that inexperienced people won't understand when evaluating complexity. They don't understand why things that work well in other things don't work well in software development. So next time you hear someone say "I think you can develop it in a few days", don't fret whoever said it. Take a deep breath, tell him the address of this article, and what else to do.