The problem you solve is more important than the code you write

Programmers seem to have forgotten the real purpose of the software is to solve real problems.



50 years ago, in 1968, a working conference on software engineering was organized, which was organized with the support of the NATO Science Committee. At that time, people began to notice that software was becoming a fundamental part of society. However, it also became too difficult to understand. After this conference, programming has become an industry. And it began to move away from controlling business people.



No matter which way programming has gone since then, there is still a problem with the separation between business and software development — or “ENGINEERING,” as the conference first called it. If developers are too focused on development, they may miss the goal of the software they write. They may not see hidden solutions that do not require any code.



Here is an example.



There was a startup that created a device that allowed a person to open the door of his house via Bluetooth. A widget was used as a visual interface, which was visible even when the phone was locked. He had a single button called "Open the door."



When the user came closer to home, he took the phone, found the widget and then pressed a button to open the door.



Someone looked at it and asked:

If we use Bluetooth and our business model lets anyone who has a phone into the house, why should we force someone to take the phone and press the button? Let the door open when the device approaches 1 meter. Thus, we do not need to pay for the development and programming of the visual interface!

This Bluetooth story is a great example of a narrow focus: the goal was to open the door with minimal effort. It makes no sense to develop a visual interface if the sensors are wireless.



If you know what goals the business wants to achieve and what is of value to the user, then you can combine this knowledge with your knowledge of technology. Only then will you have enough information to come up with the best answers and conclude that the product does not need an interface.



This is a great example of how to solve a technical problem without having to write any additional code besides the unlock code. However, as with Tech Debt , nothing should justify writing shitty code.

Not every code is worth writing

Sometimes fixing a serious bug may not be a priority. If you have a crypto exchange and the same payment was made twice in the system, human intervention may be the best solution in terms of costs and benefits, if the cost of solving this problem is high.



This trade-off between Seriousness and Priority reminds me of the model my colleague recently showed me. It is called the “Priority Matrix,” a two-dimensional model that can be used to prioritize errors based on the number of users they affect and the severity.







The re-deposit problem described above falls into the category of inconvenience affecting one user. Therefore, priority 3.

Not every bug is worth fixing.

This is a very common thing when developers try to write a script for everything. However, some repetitive tasks are not worth automating. You do not need to spend time programming scripts if you are going to hide the necessary knowledge about how the main team works.



There is a difference between encapsulating complex logic and abstraction of useful knowledge. Sometimes the information needs to be made clear. If you abstract them, they may have the opposite effect and will be more difficult to understand.



It is more useful to use some types of low-level commands in the CLI than a high-level command that abstracts knowledge, such as Git .



A few years ago I was working on a project using incremental delivery . It was an identity verification system that required the user to provide some personal data for verification by a third-party provider.



This was a special field validation feature that the team wanted to create. However, the audit history was prioritized in planning each sprint, as the deadline was getting closer and closer. In the end, the team found out that there was no point in having bizarre validation at all.



And here's why: the check was mandatory!



It is in the interest of the user to provide reliable information. If the user provides incorrect data, they will not be verified and they will not be able to use the system. In addition, most browsers supported standard HTML validation, which was pretty good.



In the worst case scenario, users who could not verify themselves could call support to check everything manually.

Not every function is worth programming.

If you are a developer and you understand the problem that you are trying to solve, you can come up with better code, and sometimes you can cope without the code at all. You are not a " Code Monkey " who is paid to write characters on the screen. You are a professional who gets paid to solve problems.



However, if you try to solve all problems using technology, without any thought, you will have problems understanding what is valuable to the client and coming up with great ideas.



Your goal and the goal of the code you wrote is to create value and make the existing world a better place, and not to satisfy your egocentric view of how the world should be.



There is a saying: "If you have only a hammer, everything looks like a nail."



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



That is, if you need a nail first.



Thanks for reading the article!



If I have errors in the translation, please write about it in the comments!

Also check out my site for quick access to javascript questions and answers - JavaScript Questions and Answers



I will be very grateful and grateful to you)



I'm on Twitter and VK



Thank you very much for your attention!