Avoid narrowing the road, programmers must remember: solving problems is more important than writing code

Avoid narrowing the road, programmers must remember: solving problems is more important than writing code

When you have a hammer in your hand, all things are nails. Sometimes programmers often fall into the vicious circle of writing code for the sake of writing code, without realizing that the code is to solve real problems. When a problem has a simpler solution, writing code may not be necessary.

Remember: You are not a programmer who spends money on you to write characters on the screen, but a professional who asks you to solve problems. Fagner Brack's summary is very insightful.

The programmer seems to have forgotten what the real purpose of the software is to solve real-world problems

The hammer was placed on a wooden board. The plank has a nail bent by a hammer.

The programmer seems to have forgotten what the real purpose of the software is to solve real-world problems.

There was a meeting in 1968 50 years ago. The name of the meeting was the Software Engineering Working Conference, which was sponsored by the NATO Scientific Committee. At that time, everyone had begun to notice that software was increasingly becoming the foundation of society. However, the software has also become too difficult to understand. After that meeting, it became an industry. Software began to get rid of the control of business people.

No matter what kind of development path the software has since then, there is still the problem of separation of business and software development (or engineering, as it was first said at that conference). If developers focus too narrowly on development, they will miss the purpose behind the software they write. You may not see potential solutions that do not require writing any code.

for example.

There is a start-up company that makes equipment that allows people to use Bluetooth to unlock and open the door. The visual interface that communicates with this device is a small program that can be seen even when the door is locked. There is a button called "Open Door".

When users approach the house, they will take out their mobile phones, find the applet, and click the button to open the door.

Someone asked after seeing this set of procedures:

If we are using Bluetooth and assuming that anyone with this phone can enter the house, why do we need someone to take out the phone and press the button? When it detects that the device is within 1 meter away, can you just let them open? This way we don't have to pay the cost of designing and writing a visual interface!

This Bluetooth application story is a great example of too narrow focus: the goal is to open the door as easily as possible. It is meaningless to design a visual interface if the sensor is wireless.

If you are aware of what the business wants to achieve and what the value to users is, you can combine which knowledge with your knowledge of what technology can do. Only then will you have enough information to come up with better answers and conclude that the interface is unnecessary for the product.

This is an excellent example of solving a programming problem-there is no need to write any additional code besides the unlock function. However, just like technical debt, nothing should be used as an excuse for writing junk code.

Not all code is worth writing

Sometimes, fixing major bugs may not be a priority. Assuming you are an encrypted digital currency exchange, if your system allows one copy of your account, human intervention will be the most cost-effective solution-if the cost of fixing the vulnerability is high.

The trade-off between severity and priority reminds me of a model that a colleague showed me recently. This model is called the priority matrix. This is a two-dimensional model that can be used to determine the priority of a bug based on the number of users affected and its severity.

Diagram of a two-dimensional priority matrix. The Y-axis represents the affected users, including the values of "one", "some", and "all" respectively. The X-axis represents the "severity," the value includes "interface", "causing inconvenience" and "unable to work." The priority of the bug depends on its position on the coordinate. For example, if the ug is interface and only If it affects a user, the priority is 4; if the bug makes someone unable to work and affects some people, the priority is 1; if the bug causes everyone to be unable to work, the priority is the highest, 0.

The single account copy problem mentioned earlier can be regarded as affecting the convenience of a user, so its priority is 3.

Not all bugs are worth fixing

It is very common for developers to want to script everything. However, some repetitive tasks may not be worth automating. If you intend to hide some basic knowledge about how low-level commands work, you don't need to spend time writing scripts.

There is a difference between the complex logic of clothing and abstract useful knowledge. Sometimes, the information should be clearly stated to facilitate understanding. If you abstract the information, it may have the opposite effect and be difficult to understand.

It is more useful to use some types of low-level commands in the CLI instead of high-level commands that abstract knowledge (such as Git aliases).

Not all commands are worth scripting

I did a project with Incremental Delivery a few years ago. This is an identity verification system. The system allows users to submit some personal data for verification by a third-party provider.

The team wants to develop a great field validation function. However, verifying this feature is listed as a low priority every sprint plan, and the deadline is getting closer and closer. In the end, the team found that this feature was not necessary at all.

The reason is: verification is a must!

Providing legal information is in the interests of users. If the data provided by the user is wrong, the verification will not pass and the system cannot be used. In addition, most browsers support standard HTML validation, which is sufficient.

In the worst case, a user who fails to pass the verification will call support for manual verification.

Not every feature is worth writing

As a developer, if you understand the problem you are trying to solve, you can come up with better code, even sometimes without coding at all. You are not a programmer who spends money to let you write characters on the screen. You are a professional that others spend money to help solve problems.

However, if you try to solve every problem with technology without thinking, it's like treating the code as a silver bullet, it will be difficult for you to understand what is valuable to the customer, and it is difficult for you to come up with good ideas.

Your purpose and the purpose of the code you write are to generate value and make the world a better place, not to satisfy your self-centered worldview.

There is a saying that goes like this: "When you have a hammer in your hand, all things are nails."

It is better to have a nail first so that you will consider the need for a hammer.

In other words, if you already need nails.

The original publication time is: 2018-07-04
This article comes from the " Java Programmers Alliance ", a partner of the Yunqi Community . For related information, please follow the " Java Programmers Alliance "