Software Architect-generals who are not good soldiers are not good generals

This article is from the "Li Yun" blog, please be sure to keep this source http://yunli.blog.51cto.com/831344/251380

Last week, a colleague came to my seat and wanted to chat with me. When he saw that I was reading the program code, he asked me, "Are you writing or watching the program ?". I was reading the program, so I replied, "I am reading the program, but I also write the program myself ". As a result, he asked, "Do you think software architects need to write their own code ?". I said, "Actually it is needed ". He replied, "isn't it a good general who is not a good soldier ?". I said, "You are very innovative. I agree with it !".
Another time when I was on an MBA program, one of my classmates saw me write a program in the classroom (actually writing a book). He asked me, "Do you want to write a program yourself now ?", I answered "yes" at the time, but I was wondering, do people think that I have to write programs myself now (I have been studying MBA? (Maybe I think too much)
Today, I want to talk about how software architects should not write their own programs. At the beginning, we have to distinguish two types of architects. The first is the application layer software architect. These people are very familiar with applications (and related specifications), and their focus is to compile documents related to requirements, rather than the specific implementation of software. Generally, these people belong to the system engineering department and are called System Architects later. The other type of people is completely different. They not only have a good understanding of the application (but may not be as good as the System Architect), but also have a good understanding of the structure and design of the software, this type of people usually come from the Development Engineering Department, which is later called the development architect.
For the development architect, I think he should understand what is software design. It doesn't matter if he finally completes code writing or guides others to complete code writing. When talking to an MBA recently about software design, he suddenly asked me, "What is software design? I think the software design is too weak !". I was stunned at this sudden problem, because design in my mind is design (it seems necessary to write an article to express my understanding of design ?). But I immediately realized that this employee had a difficult problem in the software industry, that is, there was no way to measure the quality of software design in the software industry. Some people may say that the number of software bugs does not show whether the software design is good or not? This statement makes sense at first glance. But the question is, who will first use the software to get the number of bugs and then check the software quality to decide whether to buy it? Generally, when purchasing a software (or related product), you should first understand the quality of the software (Design) Before deciding to purchase it. In addition, the number of Bugs does not really reflect the design quality of the software. A small number of bugs may be caused by low product complexity, but the design quality may be poor, the high quality on the surface is actually in exchange for a lot of pain. Some people will say, isn't there a cmme? Or other quality certification systems, are these insufficient to prove the design quality of the software? Yes, I think most of the current certifications focus on the software development process, but they do not provide the design quality certification. Knowing a good software design process does not mean a good design quality. It can be said that the process and design quality are orthogonal to some extent. Therefore, no matter how agile development methods such as XP or scrum are, we cannot directly obtain software with high design quality. Why is there no design quality certification system in the industry? This has to mention a famous story in the software industry-the story of the wolf, which tells us that "the software industry has no silver bullet ". In essence, software development (including design) is highly dependent on the human brain. Therefore, it is difficult to find a general method to produce high-quality software. From the design point of view, it is almost impossible to obtain a system to evaluate the quality of software design, because it is difficult to reach a broad consensus on the design quality and extract operational principles.
If the development architect understands the importance of design, he often needs to write some code by himself to show his design ideas, or verify his design ideas. It is impossible for developers to fully express their ideas by drawing UML diagrams. In addition, a development architect who cannot think about problems from the engineer's perspective is hard to say that he is a good architect. In addition to technical work, the Development architect should also take on management work to a certain extent. For example, motivate the team to adopt good design methods and restructuring. All of these indicate that the development architect should lead engineers to work, rather than "high level, only understanding the application ", it cannot be a super editor (simply learn how to write from the developer and then write it into the requirement document ).
Different from the Development architect, it may not be surprising that the System Architect does not write code. On the contrary, they should not care about the specific implementation of the Code. Isn't such architects having to write code during their growth? Apparently not. I believe that the requirement documents written by a system architect who is aware of the importance of software design will be more instructive and developer.
Finally, I want to emphasize the importance of the development architect. In my opinion, the current software industry is actually very difficult because it lacks high-quality development architects. I didn't see any company that couldn't develop software because they couldn't understand the application requirements. On the contrary, they didn't understand what design was, which made everyone suffer a lot.
Software quality comes from design!

This article is from the "Li Yun" blog, please be sure to keep this source http://yunli.blog.51cto.com/831344/251380