To write less code, spend more time thinking.

I have said such a thing on my microblog, and I want to describe it more fully here.

@ Left Ear Mouse: Smart programmers use 50%-70% time to think, to try and weigh various designs and implementations, and then they are busy coding, debugging and testing with 30%–50% time. Smart bosses also encourage the team to do so. But the boss of the 100%-150%, the hard work of the programmer will take out the time to busy to rush the progress, rework, refactoring, and fix a lot of bugs ... As a result, the worse the team is, the busier they are, and even the more busy they are.

And in this impetuous period, coupled with the crooked thoughts of the agile consultants, they feel like software products can be accomplished in a very short period of time, so it makes the managers very excited, just as the dogs in Pavlov's conditioned reflex experiment will drool as they see the meat. They use TDD, fast iterations, ongoing refactoring, continuous integration until continuous deployment in the software development process.

Is software development really like this? Doesn't it take time to think? There are some points of view in Todd's "quality lies in the process of construction"? and "Uncle Bob and Jim Coplien the debate about TDD." I just want to express the following points:

The essence of software is design, design is a very time-consuming brain event. For software, the design is not perfect, it is always a trade-off need to weigh things, such as: Time for space, space for time, TCP or UDP, synchronous or asynchronous, data redundancy is not redundant and so on. Whether a small observers mode is a pull or a push approach requires careful discussion. These things take time and make early attempts.

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 (the people who have done the software know that writing code from scratch is painful, but because you don't think well, do it first, so later on you will face more quality problems and you'll need to spend more time and energy. Of course, the consultants will let you use the same approach as continuous integration and continuous deployment. 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. These problems can often be used to get your software design back.

Refactoring is a nightmare, and the less refactoring the better. 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 face the increase in time and human costs, the hardest thing is that you have to face the team morale because of continuous rework and gradually low and tired and slack mood.

So if you have more time to discuss the needs and possible future changes with your customers, to investigate the technical difficulties and details of implementation, to discuss with other experienced people and to examine the architecture and design, to think about design flaws, then your job will become very straight until you see the end at a 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 upgrade.

I'm working on a project that took almost 4 months to do the design, in this process, we repeatedly think, discuss, and weigh several implementations and, as far as possible, all the scenarios and details as well as possible future changes (that is, even those simple modules), a module has been rewritten at least three times, Each time it was written in half it was overthrown rewrite, our entire team is constantly in discussions with other teams, and in the continuous understanding of the system to simplify and optimize the system, and strive to achieve perfection. It now seems sensible not to use scrum rashly.

It's like we're building bridges, we need to spend a lot of time surveying terrain geology, analyzing data, thinking about possible problems (natural disasters), evaluating different designs, rather than building them up as soon as possible.

So, more time, not let you do a few more iterations, complete several modules, but can let you write less code, faster delivery of a better product.

I believe you will have a lot of questions, below is I think you may have some of the following points of view, let me reply by one article:

The first and foremost will be the deadline of the project, or the kind of project you don't have the right to live in. For example, "a Party B contract project", I think this project is "outsourced project", under the nature of this project, you can hardly have the right to speak. To this, I think, 1 as party B you should and party A in the project plan to fight for a moment, Xiao to love, move the Daniel. 2 if not, you can only make a trade-off in terms of time, range of requirements and quality. Also, in this case you need to find a way to share your stress and pain with the user and the leader. (The premise of finding this method requires you to find users and leaders what they are afraid of, hehe)

Overly designed and armchair. Some people say that there will be too much design, too much design, or spend a lot of time on design. It's possible. A project team from my last company spent more than 1 years in a non-stop meeting and design, resulting in more than 1000 bugs in release. The reason for this problem is that the design of the team is on the paper, the meeting is open the fairy, the discussion of the design are clouds. So, design is not discussion and thinking, but also need 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 on finding a bunch of farmers, of course, it does not blame you, this is China's education and the problem of the big environment, people do not think. For such a situation, I have two suggestions, 1 do what they can, so that the size of the bowl to eat how much rice. 2 encourage thinking, that fear those ideas are very unreliable, because if you do not start, then will never think.

You must use a quick iteration. Many companies are forced to be agile, and they want the product to release as quickly as possible, without adequate time to think and discuss. My advice for this kind of project is, 1, to find someone with a lot of experience. 2 The iterative process in order to structure and program logic is simple, simple, and then simple, and strive to high cohesion between the code, low coupling. Otherwise, you'll have fun when you refactor.

The entrepreneurial team must be quick. Is it good to do fast? Many times, it is not fast who can laugh to the last. There are so many examples. The first person to make it does not necessarily occupy the market, it is likely to become a pioneer.

Rich companies give the team more time to think. Wrong, you have not seen a rich company, rich companies can recruit a pile of people do not live, you can mess up the new came, and even the failure of the project to change a name again. These real rich companies only have to be quick, just a lot of people, not afraid to make wrong decisions. People like us who have no money, do things carefully, for fear of making a wrong decision.

Finally, you are welcome to express your views.

(End of full text)