Introduction: The author Chen Hao said on Weibo: "smartProgramThe staff spent 50%-70% of their time thinking, trying and balancing various designs and implementations, while 30%-50% of their time was busy coding, debugging, and testing. A smart boss will also let the team do the same. Stupid bosses, stupid programmers will take 100%-150% of the time to catch up with the progress, rework, refactoring, fix a large number of bugs... Therefore, the poorer the team, the more busy it is, and the more busy it is ." The author elaborated on this point of view.
ArticleThe content is as follows:
In this impetuous period, coupled with the mispractices of agile consultants, they feel like software products can be completed in a short period of time with high quality, this made managers very excited, just as the dogs in Pavlov's conditioned reflex experiment saw meat as excited. They use TDD, fast iteration, continuous refactoring, continuous integration, and continuous deployment for software development.
Is software development really like this? Don't you have to spend time thinking? In this regard, some of my views are in Todd's "is quality in the building process"? As mentioned in Uncle Bob and Jim coplien's debate on TDD. I just want to express the following points:
- The essence of software lies in design. design is a brain-consuming event.. For the software, the design is not perfect. It is always a trade-off, such as time for space, space for time, TCP or UDP, synchronous or asynchronous, data redundancy is not redundant. I think it should be carefully discussed whether a small observers mode is the PULL mode or the push mode. These things require time and preliminary attempts.
- TDD,Rapid Prototyping and iteration may have a negative impact on software and teams. In the beginning, you need to spend a lot of energy on your software from scratch (people who have worked on software know that writing from scratchCodeBut because you didn't think about it, you need to talk about it first, so you will face more quality problems in the future, so you need to spend more time and energy. Of course, those consultants will allow you to use methods like continuous integration and continuous deployment. But I want to tell you that this does not solve your software design flaws. For example, TDD, iteration, and prototype only focus on functional requirements and do not focus on non-functional requirements, such as performance issues, high availability issues, and system maintenance issues (module coupling issues ), and so on. These problems often allow your software to be re-designed.
- Refactoring is a nightmare. The fewer refactoring, the better.. When you maintain a complex system, you will know how terrible refactoring is (see 7 phases of refactoring code). If you haven't thought about it at the beginning, you will not only face re-design, re-architect, but also the increase in time and labor costs, the most difficult thing you have to deal with is that the team's morale is gradually low due to continuous rework and gets tired and slack.
Therefore, if you have more time to discuss your needs and possible future changes with the customer, and investigate the technical difficulties and details of the implementation, discuss with other experienced people about the architecture and design and think about the design defects. Then, your coding will become very straightforward until you can see the end at a glance, your test cases will also be well written, and you will have almost no need to refactor, so you will write less code in the future, so that your software development will become easier and easier, until the technology is upgraded.
The project I am working on now takes almost four months to design. In this process, we repeatedly think about, discuss, and weigh several implementation methods, and try to outline all the scenarios, details, and possible future changes (even those simple modules) as much as possible. One module has been rewritten for at least three times, every time it was written in half, it was overturned and rewritten. Our entire team was constantly discussing with other teams, simplifying and optimizing the system in a constant understanding of the system, and striving for perfection. It seems wise not to rush to use scrum.
This is like building roads and bridges. We need to spend a lot of time investigating the terrain and geology, analyzing data, thinking about possible problems (various natural disasters), and evaluating different design schemes, instead of creating it as soon as possible.
So,More time is not used to allow you to perform several iterations and complete several modules. Instead, you can write less code and deliver a better product faster..
I believe you will have many questions. I think you may have the following points. Let me reply one by one:
- The first is the deadline of the project, or the project that you do not have the right to live speech.For example, for a contract-type project of Party A and Party B, I regard such a project as an outsourcing project. Under such a project, it is difficult for you to have the right to speak. In this regard, I think: 1) as Party B, you should fight for it with Party A in the Project Plan. 2) if not, you can only make a trade-off between time, scope of demand, and quality. In addition,In this case, you need to find a way to share your stress and pain with users and leaders.(The premise of finding this method requires you to find out what the users and leaders fear)
- Over-design and on-paper discussion. Some people say that there will be too many designs, leading to over-design, or spending too much time on design. This is possible. A project team in my previous company spent more than a year in meeting and designing without stopping. As a result, there were more than 1000 bugs in release. The reason for this problem is that the design of this team is to talk about the soldiers on paper, the meeting is to hold a fairy meeting, and the design of the discussion is full of clouds. So,Design is not a matter of discussion and consideration. We still need to try again,I think that when your design is complete, your core code is basically complete.
- My team members are too poor to think about. First of all, congratulations on finding a bunch of coders. Of course, this doesn't blame you. This is a problem in China's education and big environment that people don't think about. In this case, I have two suggestions: 1) try your best to make the bowl as much as possible. 2) Encourage thinking. I am afraid that those ideas are unreliable because if I don't start, I will never think about them.
- Fast iteration is required. Many companies are forced to be agile. They hope that the faster the product is, the better the release, and there is not enough time to think about and discuss it. For such projects, my suggestion is: 1) find someone with rich experience. 2) In the iteration process, the architecture and program logic are simple, simple, and simple, striving for High Cohesion and low coupling between codes. Otherwise, you will have fun restructuring.
- Entrepreneurial teams must be quick. Is it good to do it quickly? Most of the time, no one will be able to laugh at the end. There are too many such examples. The first such person may not necessarily occupy the market, but may become a pioneer.
- A rich company gives the team more time to think.. Wrong. You have never seen a rich company. A rich company can recruit a bunch of people who cannot survive, and make things messy again, you can even change the name of a failed project to another project. These real rich companies only want to speed up, but only for a large number of people, not afraid of making wrong decisions. People like us who have no money are careful about what to do, for fear of making wrong decisions.
