The goal is more important than the code.

The program has a goal that is sometimes forgotten.

An image of a hammer lying on a board. A screw stuck in the board, which was heavily hammered in there.

It seems that programmers have forgotten about the purpose of the software - to solve real-world problems.

50 years ago, in 1968, the Working Conference on Software Engineering , organized by the NATO Science Committee, was held. Then they began to notice that software is becoming a fundamental part of society. And at the same time it becomes harder to understand. After this conference, programming began to turn into a real industry. It began to go out of control of the business.

Regardless of the future of the industry, there is still a problem with the division of business and software development - or “engineering,” as was first heard at the conference. If programmers are too narrowly focused on development, they may miss the goal for which the program is being created. They may miss hidden solutions that do not require code.

Here is an example.

One startup created a device that allows you to open the door at home via Bluetooth. A graphical interface for communicating with the device - a widget on the locked screen of the phone. He has one button called "Open the door."

When the user comes to the house, he takes the phone, finds the widget and presses a button.

Someone looked at this mechanic and asked:

If we use Bluetooth and assume that the owner of the phone can enter the house, why force him to take out the phone and press a button? Let the door itself unlock when the phone is within a radius of 1 meter. No need to waste time on the design and code of the graphical interface!

This is an excellent example of a narrow focus: the goal was to open the lock with minimal effort. It makes no sense to create a graphical interface if the sensors are wireless.

If you know about the business objectives and user needs, then you can combine this knowledge with your knowledge of technology. Only then will you have enough information to come up with a better solution and understand that the program does not need an interface.

A great example of how to solve a software problem without a single line of new code.except the code for actually opening the lock. But like technical debt , nothing can justify the unnecessary programming of everything else.

Not every code is worth writing.

Sometimes correcting a serious bug is not the main task. If you are cryptobirth, and the system has allowed one double deposit , human intervention can be the best solution in terms of cost-benefit ratio, if the cost of the solution is high.

Such a compromise between Importance and Priority reminds me of a model that a colleague recently showed . It is called the priority matrix — a two-dimensional model that can be used to prioritize bugs based on severity and number of affected users.


Two-dimensional priority matrix. The vertical axis represents the number of "affected" with the values ​​of "one", "several" and "all." On the horizontal axis, “seriousness” with “cosmetic”, “inconvenient” and “stop working” values ​​is plotted. The priority of the bug is determined by the position on the axes. For example, if the error is cosmetic and affects one user, the priority is 4 (minimal). If a bug stops some users, priority 1. If it stops all users, it has the highest priority.

The double deposit problem mentioned above falls into the category of inconvenience that affected one user . Thus, priority 3.

Not every bug is worth fixing.

Developers often seek to foresee all cases. But some repetitive tasks may not deserve automation. No need to spend time writing scripts, if the result will be hidden important knowledge about the work of the core team.

There is a difference between the encapsulation of complex logic and the abstraction of useful knowledge. Sometimes only clear information can be understood. If you abstract it, then you can get the opposite effect: understanding is difficult.

It is more useful to use some types of low-level commands in the CLI than high-level commands with abstract knowledge like Git aliases .

Not every team is worth a description.

Many years ago I was working on a project with an incremental delivery . It was an identity verification system that asked the user to provide some personal data for verification by a third party.

And there the team wanted to encode one unusual field validation function. Nevertheless, this validation was pushed aside at each time schedule as the deadline approached. In the end, it was decided that there was absolutely no point in this unusual function.

And that's why: validation and so compulsory!

Providing accurate information was in the interest of the user. If he provided incorrect data, they will not pass the test and he will not be able to use the system. In addition, most browsers support fairly good standard HTML validation.

In the worst case, if the user cannot be verified, he will call the support for manual verification.

Not every function is worth coding.

If you understand the essence of the problem being solved, then as a developer you can come up with a better code, and sometimes you can do without a code at all. You are not a bylocode coder who is paid to write strings for an assigned task. You are a professional who is paid to solve problems.

But you do not need to thoughtlessly solve any problem with technologies, as if the program code is a universal solution for everything. Otherwise, you will have problems understanding the needs of the client and generating great ideas.

Your goal and purpose of the code is to create value and make the world a better place, and not to satisfy your ego-centered view of what the world should be.

There is a saying: “If you only have a hammer, everything becomes like a nail.”

It is better to first see the nail, to consider the need for a hammer.

If you really need to hammer this nail.