Some Opinions on Software Engineering

At present, software talents in China have begun to focus a lot on software engineering. In the late 1980s s and the early 1990s S, Chinese character systems were sought after by Chinese people, but they have a realistic understanding of the development process in China, I think software engineering is a very important aspect, but the problems hidden behind the appearance cannot be ignored, I think there are some problems or misunderstandings in the development process. The typical examples are as follows:

1. Excellent Scholars

This problem is common. Many people think like this: management should be considered after the age of 35. This idea is the "Learning and excellence" idea. Good developers are not necessarily good managers, because the knowledge structure is not the same because of their different focuses. However, because of the traditional thinking, the leaders should be better in all aspects, so they should be "Learning" as "Shi ". In this way, not only does not improve efficiency, but rather wastes good talents. At the same time, it is also because of the traditional idea that "Shi" is more respected, and "Learning" is often considered blue-collar, therefore, many "excellent" people also have incentives to become "Scholars. I think this is an abnormal phenomenon. The status and respect of "Learning and excellence" should have corresponding judgment mechanisms. For example, system designers should be more respected than project managers. Only in this way can "Learner" design with peace of mind. "scholar" can also better play the role of "scholar.

2. Process and Stage

It is meaningless only when there is no stage in the process. We all know that the development of any software product takes a long time, and this process is also full of risks, if the process is not effectively refined, simply and strictly follow the needs, design, development, coding, and testing processes, the problem will be covered. It must be made clear that there is no absolutely successful software engineering, and it does not meet the absolute development process in all circumstances. The process of phased development only reduces the risk and segments the cake, you cannot eat it multiple times at a time. The corresponding solution in software engineering is a milestone. In most development processes, milestones play a very important role. In some development processes, incremental development and spiral development are all about expansion of milestones, however, the milestones of these development processes are defined in their own development processes.
A good development process should be as flexible as possible in risk management. I am not in favor of putting milestone stage management into detailed provisions in the development process, instead, you should be flexible in developing different products or projects. Sometimes a milestone may only be in the early stage of the demand analysis phase, but if it meets the actual development needs, I think it is a good development method. Using this perspective, I think that the definition of milestones in the RUP is somewhat rigid. The RUP is basically an evolutionary development method, and the hierarchy of evolution is clear. However, the flexibility of milestone definitions in actual development is insufficient. Of course, it is impossible for any development method to meet all requirements. In a relatively fixed requirement project, RUP still has great strengths. At this point, I prefer the MSF development method.

3. Left and Right of Software Engineering

In the past, when I was studying Marxism, I learned the concept of "Left" and "right", as defined in the following definition: "Left" refers to how to do future things now, right refers to the thing that has done the past thing now. Both of them are not good. Practically speaking, I think that the current respect for the RUP, CMM, and so on is somewhat left-leaning. From the management perspective, there are three stages of management: human management, system management, and standard management. In my opinion, RUP and CMM belong to the scope of standard management. At this stage, many companies are eager to carry out standard management, which is not the right direction. First, it is imperative to evolve the way people manage to system management. The so-called system management is to establish rules and regulations in line with the company's actual conditions, so that people can be competent to work under a game rule, so as to greatly improve work efficiency and better communicate with all aspects of development issues. Only in this way can we have a deeper understanding of the importance of standard management. Beyond this stage, we can jump directly to a higher level, just like the idea of realizing communism at this stage. Of course, the system management of a few companies is already very good, and the work efficiency is indeed very high, so let alone.

4. What kind of talent is lacking?

I remember a joke: foreigners still haven't caught the software engineering in a black room, while the Chinese are in a black room, there were no cats in it, and some people said that I had caught the cat. On the one hand, this joke shows that software engineering is still a process of continuous exploration and development. On the other hand, it also shows that software engineering in China cannot be touched. (The above is taken from "I Have a Dream" by Hu chaohui. For details, see chinabyte.com)

What kind of talent does China lack most? I think it is a System Architect. Many may say: we lack software engineers, good project managers, and ......, Yes, we do lack these people, but the most important thing is the system designer. Because we can train both the project manager and the proficient software engineering personnel, and the relative training cost is not very high, however, the system architecture engineers need years of industry experience and superb design level, which cannot be obtained in a short time.

Many people say that most of our projects are low-cost, similar to a contractor, but have you ever wondered whether there is a project that allows you to complete a very sophisticated system, how many other companies are competent ?! The reason is that many open source systems can do a lot, not because of the software engineering of these open source systems, but because some excellent system designers are involved in the design. Software Engineering can only make the work that can be done better, and cannot solve the work that can not be done. This can also explain why software engineering is important in commercial software. The reason is very simple: when everyone can do it, it is better to compare who is doing it.

Software Engineering is a mosaic attached to a building. Of course it is better to have it, but if the structure of the building is not good, the mosaic pasted on multiple trees may be just a piece of cake.

5. PairProgramPersonnel's normal understanding

Programmers require creativity, and almost everyone thinks so. However, in practice, many people have begun to talk about how to treat programmers as a gear for running machines! This is very wrong. It is a misinterpretation of Software Engineering! First, a programmer is not a typist. The reason why a programmer is important lies in his head rather than his keyboard. Programmers are not designers, so they do not need to have a macro perspective. Programmers are required to be very proficient in a certain aspect, even a small part. It is impossible for a system designer to compile a program. What he needs to grasp is the whole. In contrast, what programmers need to grasp is local. Of course, if any part is doing well, the whole is not necessarily good, and vice versa. Just think of a ship. The designer is the rudder. He needs to have macro capabilities, need to know that there is a dangerous beach, need to set up its risks, and the programmer is a hacker, he needs to be consistent with everyone, use the best boating posture, and be hardworking.

Do not think that programmers are machines. In his position, they can also know the ship's sailing trajectory. They should carefully listen to their suggestions, because, sometimes the problems of sailing are often first discovered by boating people.

6. Some standards are required for discussion.

Sometimes there is such a problem: a group of market personnel discuss with a group of technical personnel. To solve the coordination problem between the market and technology, the market personnel talk about the problem of the market, the technical staff often make public remarks about technical problems. Therefore, some standards are required for discussion! How to define this standard varies in different scenarios and environments. The technicians eventually need to solve the problems on the market, but the solution is not simple. In that case, it is impossible for market personnel to make products that truly match the market, because market personnel only see the market appearance at a certain stage. They do not clear the reasons here, nor do they know the nature of the reasons.

For example, for the layer-3 structure that people often say today, customers often need to use the layer-3 structure to solve actual problems, but they do not clear why, I just think that many people do this. I am not denying the advantages of the three-layer structure. I just said that in many projects, the three-layer structure is not necessarily required, because it will increase the complexity, flexibility requires the support of many customers (the customer clearly describes the business logic). At the same time, the benefits of a three-layer structure are truly realized, it also requires a strong designer's good design. In many small projects, there is no need to do more, and the problem of two layers is three layers.

The establishment of the standards for this discussion requires that the technical staff understand the cause of the problem and understand the essence of the problem. What I mean is not to require technicians to have a strong market view, but to promptly explain these deeper reasons to market personnel.

Simply obeying the will of market personnel is often the direct cause of Project controllability failure.

7. one-sided understanding of management;

There is a momentum that managers in software engineering should copy and execute a manual, and there will certainly be no major problems in 10, 8, and 9. But is the problem true? There is a myth about managers in software engineering-Practitioner's research methods:
Myth: we already have books on standards and procedures for building software. Do they not give people all the information they need to know?
Fact: standard books already exist, but are they actually used ?...... Are they complete? In many cases, the answer to these questions is "no ". (P.11)
We must clarify the responsibility, essence, and advantages and disadvantages of management. Good management is inaction, and the goal of management is not to manage. No matter what the premise is that there is a set of actual game rules for everyone to play the game according to the rules. Some people understand that management is followed by managers every day, and they are not always urging and scheduling. This is wrong. Such a manager hinders normal work and misinterprets management.
Therefore, the premise of excellent management is to establish a set of effective game rules that everyone can abide by to achieve efficient work under this rule.
It is wrong to think that management is about finding someone to talk to, picking people, and pushing progress. If such a problem occurs, I think that is indeed the time to review the rules defined by myself.

8. Do you have a sustainable development framework?

What are the consequences of knowing that it cannot be done? It may be like this: the project progress is too tight, there are many product problems, and every day it falls into the quagmire of the construction period ....... Many people say that the project is too tight because the market time is too tight, the project plan is not tight, and the software engineering is not in place. However, if you do: if the market time is sufficient, the project plan is strict, and the software project is in line with the actual situation, are you sure you want to complete a project that meets the user's actual needs, excellent, and low-maintenance? I don't think so.
Many people may not disagree. If the customer's requirement is to let us make some word and PowerPoint templates (there is no need to write a lotCode), We can easily meet customer needs. However, if the customer asks us to do software such as MIS, POs, or education or government affairs, our chances of success will be greatly reduced. Why? If we make other types of software as easy as a Word template, Will we still be unsure? What do we lack? Why are we not confident enough when we are working on these software?
The crux of the problem is: Whether you have a sustainable development framework. If you have a semi-application that meets your needs, you will not encounter any problems.
If you have been defeated and defeated in your work, will you ask yourself the following question: Do you have a sustainable development framework?

9. misunderstanding of the process model;

Any process model has its advantages and disadvantages. We cannot deny the advantages of the waterfall model or its shortcomings. We cannot deny the advantages of the evolutionary model or its shortcomings. The same applies to other models. Many people advocate process models such as RUP and XP, but the premise is that we must know that such models are evolutionary models with many advantages and disadvantages.
For example, when we need to create a project with clear requirements that cannot be changed for a period of time, such as a data structure class library and a communication underlying library, using the waterfall model may have better results. Why? First, the end point of any fall generation of the evolutionary model is the starting point of the next fall generation, which helps users better grasp the system and better understand the needs, however, this model is not suitable for situations where the demand is very clear. If the demand is very clear, such downgenerations can only generate more redundant documents, and more transitional designs may be generated, these are obviously a waste. Some people simply use the evolutionary model as a waterfall model and focus on one step. This approach is even more problematic!
If a one-step system is needed (that is, the demand is very clear and the demand is rarely changed), the evolution will become a waterfall. At this time, the promotion of evolution is nothing more than a few detours.

Correct understanding of the process model is a prerequisite for correct use of the process model.

10. misunderstanding of the test work;

We should pay attention to testing, but excessive attention to testing will lead to serious problems. The most important thing in testing is to discover problems. It is to ensure that there are no problems in the software submitted to the customer. From this point of view, testing is very important, but we cannot test it because of testing, many problems cannot be solved through tests.
It is right to solve the problem when it is found, just as it is not too late. However, we need to pay more attention to the source of the problem. We need to pay more attention to the review of Demand Analysis, Design Review, and code review. Eliminating problems in the cradle is always easier than fighting with problems.
Testing Software is of course important (whether it is a unit test or a system test), but this test is only a narrow sense of the symptoms of the problem. We must not ignore the test of Requirement Analysis (demand review) and design test (design evaluation). The synthesis of such tests is a broad understanding of the test in software engineering.
If you find that too many problems have been found during testing at work, you should really consider whether the problem has been "tested" in other stages. Sometimes, when there are too many dead sheep, it will be too late to complete the prison.

Testing is a narrow concept in software engineering, but we should try to understand it in a broad sense.

11. incorrect understanding of the role of the document;

Documentation is very useful in the development process, but it is not good for document flooding. Some people say that the more documents there are in the development process, the better. I think this is wrong. First, we need to clarify why documents should be written during the development process. The most fundamental role of documents is to communicate with each other! A project or product may take a long time. There may be many links in the development process, and there may be many problems and solutions. At this time, we need help from the document, a record, and a common voice. The document is just a benchmark to help develop branches and leaves. If this principle is too much and too tight, the big tree may develop very high and straight, but it is malformed. If this principle is too small and too loose, the big tree may become a bush. Document quantity and complexity are measured. The more documents, the better.
So what is the best degree? I think there are several criteria: 1. The document needs to describe the solution to the problem rather than the solution theory; because the solution theory is achieved in the formation of the document. 2. The document is complete. Each document describes a problem. You do not need to put the content of multiple documents in one document. 3. In addition to the important phase, other parts are just discussions or ideas (these can be managed effectively using other tools); 4. Do not make documents cumbersome. If so, I think it is time to consider the necessity of writing these documents.

When writing documents, we must understand why we need to write this (whether for the present or for the future ).

12. Carefully examine mythology!

In the actual implementation of software engineering, we often encounter many myths. "Software myth has some characteristics that make it deceptive ...... Software myth is still believed by many people (see software engineering-Practitioner's research method p.10). If we look at it, rather than blindly listen to it, we may find more of them.

I hope to work with you to carefully examine the myth of software engineering!