People who do not know the technology should not say that this is easy to implement.

People who do not know the technology should not say that this is easy to implement.

"This website is quite simple. All you need to do is complete X, Y, and Z. You seem to be very technical, so I believe that you don't need to spend too much time building it ."

I will receive such emails from time to time. Almost all of the people who write these emails are technically irrelevant, or are studying their first product. At first, I was always very angry when I heard people like this. Who are they talking about the time required for software development? But then I realized that even if I had to predict how much development time I would spend on my project, I could not do anything. If I can't even do it myself, why should I be angry with those people?

What really depressing me is not the mistake they predicted. The problem is that they think they can make correct estimates. As developers, we often find that on the issue of software development, a layman would naturally estimate complicated things very easily.

This is not an excuse for our anger. But this raises another interesting question: why is our native ability to predict complexity failing in programming problems?

To answer this question, let's take a look at how our brain estimates things. Some things are easy to predict for people with no experience, but some are not.

Let's think about watching a person play the guitar. Even if you have never played a guitar, you can probably guess it's easy after watching a guitar show playing Mary had a Little Lamb, A person can play it without too much technology. Similarly, when you watch someone play Pachabel's Canon in D Major, it's easy to guess, it takes a long time to practice.

Why can we quickly and accurately estimate the complexity of these two songs? This is related to the method we use to determine whether a thing is simple or complex. Our brain has some ready-made models to accomplish these things. The first one is speed-based. In this case, the brain identifies what is played every second. Based on how many things are played every second, we can easily intuitively judge the complexity of the song. Because playing a song with a guitar is a physical process and sensory activity, our brain can easily speculate on the speed and then convert it into complexity.

We have another natural assumption: volume. Think about putting a tent and an apartment together. Even if a person has never studied architecture, he can tell you that it is easier to design and build a tent than to design and build an apartment. Why? Because we naturally use physical volume as an indicator of the complexity of things.

Of course. The above two types of logical analysis are not always 100% effective. But in most cases, this is what people do and is very successful. In most cases, when evaluating the physical process, our brain will effectively associate physical things without relying on previous experiences.

Now let's talk about software. When a tech-savvy person tries to evaluate the software development time, there are two basic intuitive indicators to help them: the complexity of volume-based indicators and the complexity of Speed-based indicators. But they don't realize that the software is different from what they think. Software is essentially not tangible. No volume and speed. Its tiny components may flash on the computer screen from time to time. Because of this, when developing a web application (or any type of software), our basic intuitive feeling becomes ineffective.

This first point, speed, is clearly impossible for outsiders to evaluate the software. Naturally, they tend to use volume indicators for evaluation. Either based on the number of pages in the description document, or based on the number of functional use cases or features of the software.

Sometimes, this evaluation method is indeed effective! When there is no special design requirement for a static website, it is easy for outsiders to use this method to estimate the development time. However, in general, the volume of software development cannot reflect the complexity.

Unfortunately, the only effective method to speculate on the complexity of software is based on experience. It is not always easy to use. As a programmer, I know that based on similar feature features I have developed before, I can estimate how much time each of these feature will take to develop. Then, I add up the total time, which gives me the approximate time required to complete the entire project. However, in fact, each project encounters two or three bottlenecks during development. These bottlenecks will consume a lot of time for programmers, and you will not be able to predict them before they are met. They will drag the entire project, resulting in a delay of weeks or even months.

These are not understood by inexperienced people when evaluating complexity. They don't understand why they don't work in 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 be upset. Take a deep breath and tell him the address of this article about what to do and what to do.

Articles you may be interested in

• In php, we use the curl post method to submit data and the get method to obtain webpage data.
• Js shields mouse and keyboard events (including right-click, direction key, backspace key, F5 refresh key, etc.), compatible with IE and firefox
• Js restrictions: Only English letters and numbers can be entered. Chinese characters and other special characters cannot be entered.
• Phpmyadmin configuration file description
• Summary of the causes and solutions for slow mysql Server Query
• PHP ob_start () Functions
• It is dangerous for multiple URLs on the website to access the same content.
• Right-click the desktop and create a text document. How can I restore it?