Thoughts on Software Engineering

Management is required for projects with more than two people. Why? If there are two people, they need to communicate. If there is communication, there will inevitably be cooperation. If there is cooperation, there must be a division of labor. If there is a division of labor, there must be coordination. If there are all these, management is required. However, the management at this moment, we say, it is unwise to kill chickens and shoot mosquitoes with a knife or a high-gun. But still need to be managed.

However, does one project need to be managed? Of course not, because there are documents, code, inspiration, experience, and so on all need to be managed. However, management is completed by yourself at the moment, which can be simpler. We have already experienced debugging bugs that have been fixed over and over again, as well as searching for technologies we have previously implemented over and over again. The theory of software engineering, in the development process, is to guide how to do a good job of management, in order to obtain the availability, correctness and rationality of software. If we know clearly that this is its goal, we can leave out some of the limitations that do not apply to ourselves.

So how does it achieve this?

I think the most important and practical significance of software engineering is that it defines work functions and determines the responsibility. What does it mean? To put it bluntly, it's what people do and who is responsible for the problem. So how does it define work functions? It is implemented by dividing the software development process. Software Engineering divides software development into many relatively independent stages. Each stage is implemented by relevant personnel, and relevant personnel are responsible. Unclear division of labor and unclear rights and responsibilities are the main cause of management confusion. Therefore, even two people's projects require guidance from software engineering, because through which we can better know how to rationally divide work, divide work powers, and achieve the final result. Of course, it is very stupid to follow the dogma path.

So what is software engineering?

Software Engineering is aimed at the "software crisis. It is a kind of engineering that applies experience and theory to practice to solve various problems in software development.

What does this mean? That is to say, software engineering is used to solve practical problems. If there are no management problems in software development, software engineering does not need to be managed; if there is no document confusion in software development, software engineering does not need documents. However, if you are lucky enough to encounter this, it is all indispensable. Software Engineering is not a fixed frame, but an elastic concept. Therefore, if you do not want to apply for ISO or CMM certification, you do not need to follow the ISO or CMM specifications at a glance. The so-called "Software Engineering with enterprise characteristics" can be completely improved by absorbing existing models and specifications.

However, this does not mean that all that appears in the development process is software engineering. Only those that can guide development to success are truly meaningful software engineering. Others, only failed attempts at most.

So when should we start implementing software engineering?

Must software engineering start before a project starts? Are you sure you want to run through the entire project? Why?

No, software engineering can start at any time in the project, or end at any time that is no longer needed. Because Software Engineering divides the development process into different stages, the so-called "Life Cycle" provides different models for reference in different lifecycles.

So how does a software company implement software engineering?

First, you must know software engineering, understand software engineering, and then understand the existing software engineering models and specifications. ISO, CMM, or agility all define a set of specifications. These specifications are the accumulation of experience, technology, and theory. They have many reasonable and feasible modes that can be referenced and referenced. However, silver bullet games do not. Of course, we can start from scratch, create the wheels they have built, and let them fall. But obviously, this is not necessary.

The best implementation method is also the most feasible method. The least cost method is to modify the specifications according to objective factors of development to conform to our development process. But most importantly, it is to modify our subjective understanding to conform to those norms. The most important thing is to find and correct those unreasonable norms during implementation.

Will it become unable to adapt, and thus fall into chaos?

Yes, this is possible, so any correction should be cautious. All modification proposals should be top-down, and decisions should be bottom-up.

Does software engineering require a project scale?

We are worried that a small project application software project will fall into bureaucracy, which will increase the burden on the project?
What is software engineering? Software Engineering does not define what is software engineering! Nor does it define the scale of software engineering itself. The significance of software engineering lies in the division of the development stage, as well as the division of labor and responsibility. This does not conflict with the scale of the project. On the contrary, a smaller project requires the management of software engineering. A consensus of software development is to divide a large project into small modules, and then small modules into smaller modules. If these small modules are independent (or originally an independent project), software engineering can at least improve their reusability.

For a team with a low concept of software engineering, do not expect them to use software engineering when taking over big projects, if they are unwilling to use it in small projects. The complexity of the former is not something they can imagine and bear.

Does Application Software Engineering increase the workload?

Yes, but only for those who are relaxed in projects that do not use software engineering management. Software Engineering will make them either unemployed or take responsibility. Compared with engineers, they will be freed from the chaotic and clueless state, and their work will become efficient. The loss is the exposure of people who previously had a vegetarian meal-which may be its only defect and one of the reasons it was resisted by many companies/individuals.

What should we do?

Learning! If we don't want to re-invent a wheel.
Try! If we want to change.