Importance of thinking in software development

 

In this impetuous period, coupled with the mispractices of agile consultants,
They make people 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? This
Some ideas are in "quality lies in the building process" of Todd.
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 software, the design is not perfect. It is always a trade-off,
For example: Time for space, space for time, TCP or UDP, synchronous or asynchronous, data redundancy is not redundant, and so on.
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.
At the beginning, you need to spend a lot of energy on getting your software from scratch (people who have done software know that writing code from scratch is very painful ),
But because you didn't think about it well, let's 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, 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,
Investigate the technical difficulties and details of the implementation, discuss the architecture and design with other experienced people,
Think about design defects, so your coding will become very straight until you can see the end at a glance,
Your test cases will also be well written, and you will hardly need to refactor, so you will write less code in the future,
As a result, your software development will become easier and easier until the technology begins to replace.

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 reveal all the scenarios, details, and possible future changes as much as possible (even those simple modules ),
One module was rewritten at least three times, and was overturned and rewritten every time it was written in half. Our entire team is constantly discussing with other teams,
In addition, the system is simplified and optimized in the constant understanding of the system, and strive to achieve 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 surveying the terrain and geology and analyzing data,
Think about possible problems (various natural disasters) and evaluate different design schemes, rather than building them as soon as possible.

Therefore, more time is not used to allow you to perform multiple iterations and complete several modules. Instead, you can write less code,
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 between Party A and Party B, I regard such a project as an outsourcing project ",
In this type of project, it is difficult for you to have the right to speak.

In my opinion,
1) As Party B, you should fight for it with Party A on 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 holding meetings and designing,
There are more than 1000 bugs in result release. The reason for this problem is that the team was designed to talk on paper, and the meeting was a fairy meeting,
The design discussed is full of clouds. Therefore, the design does not discuss and think about it. I still need to try it. I think when your design is complete,
Your backbone 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,
There is not enough time to think and discuss.

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 allows the team to spend more time thinking.
Wrong. You have never seen a rich company. A rich company can recruit a bunch of people who cannot survive,
It can disrupt things and create new projects, or even change the name of a failed project and re-establish the 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.