Home > Article > Backend Development > People who are not technical should not tell people who are technical that this is easy to achieve_PHP Tutorial
“This website is pretty simple, all you have to do is complete X,Y,Z. You seem to have good skills, so I believe it won’t take you much time to set it up. ”
I receive emails like this from time to time. The people writing these emails are almost always people who have no experience with technology, or are working on their first product. At first, I always get really annoyed when I hear people say things like this. Who are they arguing with about the time it takes to develop software? But then I realized that even if I could predict how much development time my project would take, I was clueless. If I can't do it well myself, why should I be angry with those people?
What really depresses me is not the error in their estimates. 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 issues, 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 faced with programming problems?
To answer this question, let’s take a look at how our brains estimate things. Some things are easy for inexperienced people to predict correctly, but some things are not.
Let’s think about watching a person play guitar. Even if you've never played guitar, after watching a guitar performance of "Mary had a Little Lamb," you can probably surmise that it's simple and one doesn't need to be too tall The technique can be played. Likewise, after watching someone play Pachabel’s Canon in D major, you can easily deduce that it is complex and requires a long time of practice to master.
Why can we quickly and accurately estimate the complexity of these two pieces of music? This is related to the method we use to judge whether something is simple or complex. Our brains have some ready-made patterns for accomplishing these things, and the first one is 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 song. Because playing a song on the guitar is a physical process, a sensory activity, our brains can easily use this to infer tempo, and then convert it into complexity.
We have another natural basis for speculation: volume. Think of a tent compared to an apartment. Even if one has never studied architecture, one can tell you that it is often easier to design and build a tent than an apartment building. Why? Because we are wired to use physical volume as an indicator of the complexity of something.
Of course. The two logical analyzes mentioned above are not always 100% effective. But for the most part, that’s what people do, and it works. In most cases, when we evaluate physical processes, our brains make efficient connections between physical things and do not need to rely 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 indicators to assist them: complexity as an indicator of volume and complexity as an indicator of speed. But what they didn't realize was that the software was not what they imagined. Software is not inherently tangible. No size or speed. Tiny components of it may flash on the computer screen from time to time. Because of this, when it comes to developing a web application (or any kind of software), our basic intuition breaks down.
The first point, speed, is obviously impossible for laypeople to use to evaluate software. So naturally, they tend to use volume indicators for evaluation. Either based on the number of pages describing the document, or based on the number of functional use cases or features of the software.
Sometimes, this evaluation method really works! When faced with a static website, there are no special design requirements, and laymen can easily use this method to estimate the development time. However, usually, for software development, volume does not truly and effectively reflect complexity.
Unfortunately, the only valid way to guess at the complexity of software is based on experience. And it doesn’t work all the time. As a programmer, I know that based on similar features that I have developed before, I can estimate how much development time each of these features will take now. I then added up the total time, which gave me the approximate time it would take to complete the entire project. However, in fact, every project encounters two or three bottlenecks during the development process. These bottlenecks consume a lot of programmers' time, and you don't even foresee them before you encounter them. They can slow down an entire project, delaying it by weeks or even months.
These are things that inexperienced people won’t understand when evaluating complexity. They don't understand why a method that works well for other things doesn't work for software development. So, the next time you hear someone say, "I think you can develop this in a few days," no matter who said it, don't get upset. Take a deep breath, tell him the address of this article, and do whatever you need to do.