Software Development myth-above

Myth 1: myth itself.

Myth 2: as long as the development process follows the agile building process, productivity and quality can be significantly improved.

 

At first glance, the logic of this sentence is very correct. In fact, this sentence is actually a result, and the result of agility is taken as a reason by mistake. For example, it means that people who run fast must run fast. The name of Agile Methodology is amazing. It is equivalent to the name of a runner as fast as it is. Agile experts are now increasingly advocating tdd. scrum tools seem to have the path to agility in their hands.

In fact, agile originally meant:

Individuals and interactionsOver processes and tools

Working softwareOver comprehensive documentation

Customer collaborationOver contract negotiation

Responding to changeOver following a plan

That is

Human and InteractionFocuses on processes and tools.

Software that can workOver the document for full blame.

Customer collaborationOver contract negotiation.

Respond to changes at any timeMore than regular.

 

The first sentence is"Human and interaction over processes and tools", This is precisely in conflict with the so-called agile experts over-advocating the building process in agile. The original intention of agility was to change the previous rigid process that had been put too much emphasis on software development. I did not expect people who have been rigid to create a rigid process.

 

Myth 3: You can find a tool that can solve the dependency and code control problems that humans cannot solve.

 

When I was a child, everyone liked Superman. Whenever he encountered an unsolved problem, he stood up from the sea of people and helped you solve all the troubles. In the software development process, there are also many development problems. Everyone is complaining about the difficulties in the process, documents, and Code. At this time, the "expert" will take a company's product and say that he has used it, your troubles are gone. As a matter of fact, software is a tool written by people to solve problems in a certain model based on certain ideas. If people cannot solve problems, this tool is basically powerless. Any tool requires the operator to configure it according to certain rules and give it correct input so that it will give you what you need. It feels like a robot dog, if you touch it, place your tail. If you have to manipulate him in an incorrect way, you will naturally not get the correct result. It does not think about it. It only solves the problems in the problem model. What is the only advantage? It is very fast. It's a pity that people who think about it will give it a lot of money...

 

Myth 4: good software design can adapt to all changes in demand

 

For a while, the design model was on the rise, and the design model was required for interviews.GOF has never been known in my life.All books emphasize the importance of adapting to changes in requirements. At that time, the software must be written on three layers. The data access layer, service layer, and performance Layer have no service logic at all for some simple requirements, the data access layer is called directly. Some interfaces do not have other implementations. In order to consider scalability, everyone has made their extended interfaces to the extreme. As a result, the scale of software expands rapidly, and the amount of code maintenance is greatly increased. It is costly to develop programs. The design emphasizes scalability, and the performance and maintainability of the software are greatly reduced. On the other hand, why should a software working in a specific environment be able to meet requirements that exceed a specific environment? In fact, there is still no further consideration for user needs. As a user, I certainly want to buy a horse that runs fast, does not eat grass, and is also cheap. Then, as a salesman, you have to find such a horse for the user? Of course, I do not deny that we really need to rely on the user's needs, but we need to carefully analyze the user's needs to find him the cheapest horse to meet his needs. The real responsibility for users is actually to stand on his standpoint and think about what he really needs...

 

Myth 5: anyone who is missing in the software development process is required to strengthen management.

 

I once heard a PM saying that I want to introduce the pipeline method into software development. I think that development is like the workers on the pipeline. Every person can assemble the software into the software according to the software development process, stable and efficient. For example, it is inappropriate to use software. A single pipeline can only produce one type of products. Everyone is very clear about the Assembly and structure of this product. Software products are almost different. If they are the same, they do not need to be assembled. Direct copying is more efficient than pipeline. A good software product is a trace of an evolutionary thought formed by fully understanding specific user needs, design, development, and testing. Different people may have different styles to do it. If you only want to make the same product as the pipeline to meet different customers, you can use the pipeline to manage personnel, but remind you that you do not need the pipeline, just copy...