"This site is pretty simple, all you need to do is complete x, Y, Z. You look like you're technically good, so I'm sure you don't have to spend too much time building it up. "I get this email from time to time. Most of the people who write these messages are people who are not technically close, or are studying their first product. At first, I was always very angry when I heard people say that. Who are they arguing with about the time it takes to develop software? But then I realized that even if I had my own projections of how much development time to spend on my project, I was helpless. If I can't do it myself, why should I be angry with those people?What really depressed me was not the mistake they had predicted. The problem is that they think they can make the right estimate!!! as developers, we often find that in software development, a layman will naturally estimate the complexity of the matter. It's 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 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, and after watching a guitar show with a Little Lamb (Mary had a Little Lamb), you can probably deduce that it's simple, and that a person can play it without too much skill. Similarly, when you watch 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 can we quickly and accurately estimate the complexity of these two tunes? It's about the simple and complex way we use to judge a thing. Our brains have some out-of-the-box patterns to accomplish these things, the first one being based on speed. In this case, the brain will discern what is played 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, and our brains can easily speculate on the speed and then transform it into complexity. We also have another natural basis for speculation: volume. Think about putting a tent and an apartment in a comparison. 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 are born with physical volume as an indicator of the complexity of things. Of course. The two logic analyses above are not always 100% effective. But in most cases people do it and are successful. In most cases, when we evaluate our physical processes, our brains are effectively associated with 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 basic visual indicators to assist them: the complexity of volume as the indicator and the complexity of speed. But they did not realize that the software was different from what they had imagined.software is essentially not a tangible substance. No volume and speed. Its tiny components may occasionally flash on a computer screen. Because of this, our basic sense of intuition is ineffective when it comes to developing a Web application (or any type of software). The 1th, the speed, is obviously impossible for the layman to evaluate the software. Naturally, they tend to use volumetric indicators for evaluation. Either according to the number of pages describing the document, or according to the software's functional use cases or the number of features. Sometimes, this assessment means it works! When faced with a static website, no special design requirements, it is easy for laymen to estimate development time in this way. However, in general, for software Development, volume does not reflect complexity realistically and effectively.Unfortunately, for software complexity, the only effective way to speculate is based on experience. And it's not always good. As a programmer, I know that, based on the similar features I've developed before, I can estimate how much development time each of these features will take. Then, I gross position the time to add up, and this gets the approximate time required to complete the project. HoweverIn fact, each project encountered a two or three bottleneck during the development process. These bottlenecks can take a lot of the programmer's time, and you won't be able to foresee them before you meet them. They stall the whole project, causing the schedule to be delayed for weeks or even months. These are inexperienced people who do not understand the complexity of the assessment. They don't understand how it's going to work in other ways, and why it's not in software development. SoThe 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 the article and what to do.
People who don't know the technology, don't say it's easy to do with people who know the technology.
