I have said such a passage on my microblog, and I would like to make this point more complete here.
Smart programmers use 50%-70% time to think, try and weigh various designs and implementations, while using 30%–50% time is busy coding, debugging and testing. A smart boss will let the team do the same. And the boss of the stupid, bitter programmer will take out 100%-150% time to busy with the progress, rework, refactoring, fix a lot of bugs ... Therefore, the worse the team is generally more busy, but also busy.
In this impetuous period, coupled with the tilt of the agile consultants, they make people feel like the SOFTWARE product can be done in a short period of time, which makes the managers very excited, like Pavlov's reflex test dogs see meat will drool as excited. They use TDD, fast iterations, continuous refactoring, continuous integration, and continuous deployment methods for software development.
Is software development really like this? Don't you have to take the time to think? In this respect, some of the points of view in Todd's "quality lies in the construction process"? "and" Uncle Bob and Jim Coplien the controversy over TDD. " I just want to express the following points:
- The essence of software is design, design is a brain-consuming event . For software, the design is not perfect, it is always a need to trade-offs, such as: Time for space, space for time, TCP or UDP, synchronous or asynchronous, data redundancy is not redundant and so on. Even a small observers pattern is a pull or push approach that needs to be discussed carefully. These things take time and do a pre-trial.
- TDD, rapid prototyping, and iterations can have a negative impact on software and teams . In the beginning, you need to spend a lot of effort to make your software from scratch (people who do software know that writing code from scratch is very painful), but because you do not think well, do it first, so, later you will face more quality problems and make you need to spend more time and energy. Of course, those counselors will let you use continuous integration and continuous deployment of such methods. But I want to tell you that this does not solve your software design flaws. For example,--TDD, iterations, and prototypes focus only on functional requirements and do not focus on non-functional requirements, such as performance issues, high availability issues, system maintenance issues (module coupling issues), and so on. And these questions can often make your software design come back.
- Refactoring is a nightmare, and refactoring should be as little as possible . When you maintain a complex system you will know how scary it is to refactor (see the 7 Phases of refactoring code). If you do not think well at first, you have to face not only re-design, Re-architect, but also to face the increase in time and labor costs, the hardest thing is that you have to face is the team morale because of constant rework and gradually depressed and produce boredom and slack mood.
So, if you can have more time to discuss the requirements and future changes with the customer, to investigate the technical difficulties and details of the implementation, to discuss and refine the architecture and design with other experienced people to think about the design flaws, then your coding will become very straight until you see the end at one glance, Your test case will also be very good, you will almost no need to refactor, so you will write less code in the future, so that your software development will be more and more relaxed, until the technology began to make a replacement.
The project I'm working on now takes almost 4 months to design, and in the process, we think, discuss and weigh several implementations, and as much as possible to make all the scenes and details as well as possible future changes (even those simple modules), a module has been rewritten at least three times, Every time it's written halfway down the rewrite, our entire team is constantly discussing with other teams and simplifying and optimising the system in a constant awareness of the system and striving to achieve perfection. It seems that it is wise not to use scrum rashly.
It's like we build bridges, we need to spend a lot of time surveying topographic geology, analyzing data, thinking about possible problems (natural disasters), evaluating different designs, and not building them as soon as possible.
So, more time, not to let you do a few more iterations, more than a few modules, but can let you write less code, faster delivery of a better product .
I believe that you will have a lot of questions, below is I think you may have some of the following points, let me one article to reply:
- the first one will be the project. deadline , or the kind of project you don't have a right to live in. For example, "a Party B contract project", I think this project is "outsourcing project", in the nature of this project, you can hardly have a voice. In this, I think, 1) as party B you still should and party A in the project plan to fight for a bit, Xiao to love, move with reason. 2) If not, you can only make a trade-off between time, scope of demand and quality. Also, in this case you need to find a way to share your stress and pain with the user and the leader. (Finding the premise of this method requires you to find the user and lead them to fear what, hehe)
- over-design and armchair . Some people say they will design too much, cause excessive design, or spend too much time on design. This is possible. A project team from my last company spent more than 1 years in meetings and design, with more than 1000 bugs in release. The reason for this problem is that the design of the team is on paper, the meeting is open fairy meeting, the design of the discussion is a cloud. Therefore, the design is not discussion and thinking, but also to try, I think when your design is complete, your backbone core code is basically completed.
- my team members are too poor to think . First of all, congratulations to you to find a bunch of farmers, of course, this does not blame you, this is China's education and the big environment of the problem, so that people do not think. For such a situation, I have two suggestions, 1) Do what you can, so how many bowls to eat. 2) Encourage thinking, that is afraid of those ideas are not reliable, because if not to start, then will never think.
- fast iterations must be used . Many companies are aggressively agile, and they want the product to release as quickly as possible without sufficient time to think and discuss. For this kind of project, my advice is, 1) find someone with a lot of experience to do it. 2) in the iterative process, we strive for the simplicity, simplicity and simplicity of the architecture and program logic, striving for high cohesion and low coupling between the code. Otherwise, you'll have fun when you refactor.
- The entrepreneurial team must be quick . Is it good to do it fast? Many times, it is not who is quick who can laugh to the last. There are too many examples of this. The first person who does not necessarily occupy the market, it is likely to be a pioneer.
- a rich company will give the team more time to think . Wrong, you have not seen the rich company, the rich company can recruit a bunch of people who can not live, could confuse things and then new, and even to do the project of failure to change a name and then re-project. These really wealthy companies are just quick, asking for more people, not afraid to make wrong decisions. People like us who have no money, do things carefully, for fear of making the wrong decision.
More time to write less code
