About “good enough” software
Today at the daily Stand-up, I made a very heartfelt speech to the team that we are writing software for people and are not interested in how beautiful the code will look from the inside if the user is uncomfortable working with him.
I also talked about the fact that you cannot endlessly polishing the same piece of code, grabbing it in the middle of a project, that the main value of a product is a business feature, not a code, and that moving forward is impossible if you get stuck in place and engage in makeovers.
And, of course, I immediately remembered the concept of good enough (good enough) software. So, here is her main postulate: we don’t strive to make it perfect, we don’t write at random, we make a fairly good product.
What does it mean? This means we understand that in any system there are errors, the code and architecture of any system is imperfect, and the functionality can always be supplemented. But we put up with it and treat these shortcomings as a necessary evil, not allowing them to overcome a certain threshold that is critical for this type of application. In this article, I will touch on the concept of “good enough” product quality, code, and functionality.
')
We do not suffer from youthful maximalism and do not spend infinite time reducing the number of errors to zero. And this is impossible (if someone wants, it can be proved purely mathematically). We also understand that, depending on the purpose of the system, the error threshold should vary.
Obviously, there should be no errors in the vital parts of the business logic in the patient life support system in the hospital or the aerodrome control software. But a completely different approach is applied to the development and testing of such applications, and a completely different time and budget is put into testing.
In the average business application, the number of errors and omissions can be quite large. Sometimes, terribly big. And, nevertheless, the system will be quite successful, unless, of course, there will be failures in most standard use cases. We will not consider this software ideal, but we will consider it to be good enough .
The same applies to the code. The code may not be perfect. Attempts to write perfect code always end in ripped budgets. The well-known expression “it's better to lose a day, but then fly five minutes later”, very useful for combating hack, “plasticine” architecture and a subconscious dump in the code (I will definitely write about this) acquires a completely destructive meaning in this context.
We lose day by day, honing our flying skills, but we are not going to fly anywhere. We cannot stop and say: “Everything! Now you can fly, ”because there are always a couple of not fully mastered flight techniques: a barrel, a loop of Nesterov, and other (equally unnecessary in civil aviation) tricks.
So let's confine ourselves to a fairly good implementation. No one even argues that it can be better. But even this code completely satisfies our requirements for functionality, it is quite understandable, it scales well enough , and it is easy to change it.
Have you ever wondered if your users need “this cool feature”? Unfortunately, most programmers have a tendency to work on the principle “the more the better”. The product, even before the release of the first version, is overgrown with functions like mushrooms after rain. For additional "interface improvements", "adding the ability to do something else" and creating a "flexible system that allows users to do everything" is lost the main idea, the main feature of the application, the main key to success.
Here I, of course, am not talking about products, the main raisin of which is to allow the user to “do everything”. These, too, are. For example, one of our products (I will not specify that I was not announced in advertising;) is based on this advantage .
Look on Twitter. Its functionality is minimal. It is sufficient for users to send their messages and read other people. Neither the ability to add pictures to messages (“how can you do without them,” many will think), nor a full-fledged sociality (only Follow and reply), nothing superfluous.
Look at google. He never did the categories that all search engines had at that time and it was hard to imagine how “you can do without them”.
The more features you try to add to the product, the more its main advantages are blurred. Therefore, the functionality should be sufficient to perform the basic task for which you created it.
So, I would like to note a very important point: I do not in any way urge you to quit writing carefully and start “sausage”. Products that live for a long time will never forgive you. I do not urge to release software with a huge number of errors in critical places. I'm not saying that rich functionality is bad.
I urge you only to get rid of the stereotype that your system should be perfect. This is a fantasy and, in pursuit of it, you can lose quite real time, money and unique chances to release a really necessary, important and interesting product exactly when there is a need for it.
I also talked about the fact that you cannot endlessly polishing the same piece of code, grabbing it in the middle of a project, that the main value of a product is a business feature, not a code, and that moving forward is impossible if you get stuck in place and engage in makeovers.
And, of course, I immediately remembered the concept of good enough (good enough) software. So, here is her main postulate: we don’t strive to make it perfect, we don’t write at random, we make a fairly good product.
What does it mean? This means we understand that in any system there are errors, the code and architecture of any system is imperfect, and the functionality can always be supplemented. But we put up with it and treat these shortcomings as a necessary evil, not allowing them to overcome a certain threshold that is critical for this type of application. In this article, I will touch on the concept of “good enough” product quality, code, and functionality.
')
Quality
We do not suffer from youthful maximalism and do not spend infinite time reducing the number of errors to zero. And this is impossible (if someone wants, it can be proved purely mathematically). We also understand that, depending on the purpose of the system, the error threshold should vary.
Obviously, there should be no errors in the vital parts of the business logic in the patient life support system in the hospital or the aerodrome control software. But a completely different approach is applied to the development and testing of such applications, and a completely different time and budget is put into testing.
In the average business application, the number of errors and omissions can be quite large. Sometimes, terribly big. And, nevertheless, the system will be quite successful, unless, of course, there will be failures in most standard use cases. We will not consider this software ideal, but we will consider it to be good enough .
Architecture and code
The same applies to the code. The code may not be perfect. Attempts to write perfect code always end in ripped budgets. The well-known expression “it's better to lose a day, but then fly five minutes later”, very useful for combating hack, “plasticine” architecture and a subconscious dump in the code (I will definitely write about this) acquires a completely destructive meaning in this context.
We lose day by day, honing our flying skills, but we are not going to fly anywhere. We cannot stop and say: “Everything! Now you can fly, ”because there are always a couple of not fully mastered flight techniques: a barrel, a loop of Nesterov, and other (equally unnecessary in civil aviation) tricks.
So let's confine ourselves to a fairly good implementation. No one even argues that it can be better. But even this code completely satisfies our requirements for functionality, it is quite understandable, it scales well enough , and it is easy to change it.
Functionality
Have you ever wondered if your users need “this cool feature”? Unfortunately, most programmers have a tendency to work on the principle “the more the better”. The product, even before the release of the first version, is overgrown with functions like mushrooms after rain. For additional "interface improvements", "adding the ability to do something else" and creating a "flexible system that allows users to do everything" is lost the main idea, the main feature of the application, the main key to success.
Here I, of course, am not talking about products, the main raisin of which is to allow the user to “do everything”. These, too, are. For example, one of our products (I will not specify that I was not announced in advertising;) is based on this advantage .
Look on Twitter. Its functionality is minimal. It is sufficient for users to send their messages and read other people. Neither the ability to add pictures to messages (“how can you do without them,” many will think), nor a full-fledged sociality (only Follow and reply), nothing superfluous.
Look at google. He never did the categories that all search engines had at that time and it was hard to imagine how “you can do without them”.
The more features you try to add to the product, the more its main advantages are blurred. Therefore, the functionality should be sufficient to perform the basic task for which you created it.
A few lines at the end
So, I would like to note a very important point: I do not in any way urge you to quit writing carefully and start “sausage”. Products that live for a long time will never forgive you. I do not urge to release software with a huge number of errors in critical places. I'm not saying that rich functionality is bad.
I urge you only to get rid of the stereotype that your system should be perfect. This is a fantasy and, in pursuit of it, you can lose quite real time, money and unique chances to release a really necessary, important and interesting product exactly when there is a need for it.
Source: https://habr.com/ru/post/122363/
All Articles