Deep understanding of technology people

"This site is very simple, so all you have to do is finish x,y,z." You look like the technology should be good, so I know that there is not much time you can build it successfully. ”

I often get similar emails. Most people who are not technically competent will write these emails or are studying their first product. At first, I was always very unhappy when someone told me that. Who are they debating about the time it takes to develop software? Slowly I realized that even if I had to predict How much development time my project would take, I could do nothing about it. If I can't do it myself, why should I be angry with others?

What really bugs me is not their predictions. The problem is that they think they can make the right estimates. As a developer, we often find that in the case of software development, it is natural for a layman to estimate complex things simply.

This is not an excuse for our anger. But this raises another interesting question: why do our innate ability to predict complexity fail when confronted with programming problems?

To answer this question, let's understand 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 man play the guitar. Even if you've never played a guitar, after watching a guitar show that Mary has a lamb (had a Little Lamb), you can probably speculate that it's very simple, a person who doesn't need too much technology to play. Also, when you watch someone play the canon (Pachabel's Canon) in D major, it's easy to speculate that it's complicated and takes a long time to play.

Why is it that we can quickly and accurately estimate the complexity of these two pieces of music? This is related to the way we use to judge a simple and complex thing. Our brains have some ready-made patterns to do these things, first one is based on speed. In this case, the brain can tell what to play every second. Depending on how many things are played per second, it is easy to have an intuitive sense of the complexity of the song. Because playing a song on a guitar is a physical process, a sensory activity, it's easy for our brain to speculate on speed and then turn into complexity.

We have another natural basis for speculation: volume. Think about comparing a tent with an apartment. Even if a person has never studied architecture, he can tell you that it is usually easier to design and build a tent than to design and build an apartment. Why? Because we are naturally using physical volume as an indicator of the complexity of things.

Of course. The two logical analyses mentioned above are not always valid for 100%. But in most cases, that's what people do, and they're successful. In most cases, when we evaluate the physical process, our brains have an effective connection to physical things, and we don't need to rely on previous experience.

Now let's talk about software. When an ignorant person tries to evaluate software development time, there are two very basic intuitive indicators to assist them: the complexity of the volume as the indicator and the complexity of the speed. But they didn't realize that the software was different from what they had imagined. Software is not a physical substance in nature. No volume or speed. Its tiny components may occasionally flash on a computer screen. Because of this, when faced with the development of a Web application (or any type of software), our basic intuitive feeling is not valid.

The 1th, the speed, is obviously impossible for the layman to take to evaluate the software. Naturally, they tend to use volume indices for evaluation. Either according to the number of pages that describe the document, or according to the functional use cases or characteristics of the software.

Sometimes this assessment is effective! When faced with a static web site, there is no particular design requirement, and it is easy for laymen to estimate development time in this way. However, generally, for software development, volume does not reflect the complexity of real and effective.

Unfortunately, the only effective method of inferring software complexity is based on experience. And it's not always easy to use. As a programmer, I know that I can estimate how much development time each of these features now has, based on similar functional features I've developed before. Then I add up the total time, which is the approximate time required to complete the project. However, in fact, each project encountered two bottlenecks during the development process. These bottlenecks consume a lot of the programmer's time, and you don't anticipate them until you meet them. They stall the entire project, delaying the duration for weeks or months.

These are inexperienced people who do not understand when evaluating complexity. They don't understand why it's not good for software development to have a very spiritual approach to other things. 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 annoyed. Take a deep breath and tell him the address of this article and what to do with it.

English original: I ' m throaty It'll only Take you A Few