The art of programming under Unix (and not only). Part Five, “the rule of simplicity”
I continue the series of articles devoted to some simple rules for developing under Unix “according to Eric Raymond ”, which, in my deepest conviction, can be extended to any other operating system. I have already told in the first three parts about the rules of modularity , clarity , composition and separation . Today it came to the fifth rule -
Rule number five: add complexity only where it is really needed (Design for simplicity; add complexity only where you must.)
When designing various information systems, I often say to myself “stop: it’s harder than it should be” and go back to the beginning in order to understand what went wrong. The complexity of the system is not so much the cost of support as the cost of development. The answer to the question of what consequences a change will entail for a sophisticated system will require much more time than a business requires. Step by step, the system dies and among programmers they begin to express more and more boldly the thoughts about a complete reworking of the entire product.
')
I wrote earlier about the KISS principle and “Occam's razor”, in an article about the principle “clarity is better than cleverness”. Therefore, I will present this article in the form of a digest of other people's thoughts on the topic of simplicity and complexity.
Antoine de Saint Exupery said on this occasion the most excellent thought, " As you can see, perfection is achieved not when there is nothing to add, but when nothing can be taken away ." Remember the times when a new iPhone appeared: banter on the topic “what the iPhone doesn’t have and my grandmother’s pensioner phone” was the leitmotif of all forums. Because in order to be good and in time, it was all superfluous. The Chinese, as we see, think exactly the opposite.
When addingsomething new to a sufficient one, ask yourself each time how much effect it will have, whether you could evaluate it or just guesses. Especially in the second case, leave the opportunity then painlessly "cut off".
Perl has a couple of mottos attributed to Larry Wall. The first is “ There is more than one way to do this ” (There's More Than One Way To Do It. There is even a reduction for this - TMTOWTDI). The second is “ Simple things should be simple, and complex things should be possible ” (Easy Things should be possible). The situation when the developer cannot relatively quickly answer the question of the feasibility of improvement and at least roughly estimate the labor costs and the necessary changes should be alarming. So, now it’s not the developer who manages the system, but she to them ...
Particularly should strive for simplicity in data structures. Eric Raymond, in his book, Cathedral and Bazaar , uttered a very correct idea: " Good data structures and bad code work a little better than good code and bad data ." Tinkering with the system "anew" the main difficulty is often the data and the mistakes made in the design. Just last week, I interviewed a programmer who, in response to a question about the correct, in his view, variant of storing address information, offered to store everything in one field, sharingsome rare symbol. Immediately all subsequent questions disappeared.
Another expression on this subject is attributed to Ludwig Wittgeinstein , “ A good architect is different from a bad one in that the bad one is tempted, and the good one avoids him ”. It is thesame in programming: if you want to add something , stop, write down on a piece of paper and continue to work as it worked. If you design a system from scratch, leave only the most necessary, and then thoughtfully add small “excesses” (you don’t need to add them without quotes).
A lot of complications occur at the level of product specification development, when the customer finally understands what he wanted at the very beginning (the second time he understands this when he sees the first prototype, and the third when everything has already been implemented). Complicating the specification is very simple - literally everything has to do with it. It will be very difficult to work on it. Therefore, it is necessary to follow the rule: the price of any change includes not only this change, but analysis of the impact and price of bookmarks on highly probable extensions (including removing this change if necessary). It is clear that with an increase in the number of requirements, the price of such changes increases, both in the project documentation and in the product. Therefore, as soon as possible, I recommend adding all non-key requirements that come in addition to the next stage in order to start the first as soon as possible in order to get the prototype and the first release as soon as possible. Let it be simple, albeit insufficiently functional, but ready for tests for performance, usability, reliability.
I will conclude today's article with the famous expression of Oscar Wilde , the confirmation of which I meet literally at every step: “ There is nothing difficult in life. That we are complex. Life is a simple thing, and in it what is simpler is the more correct . ”
Rule number five: add complexity only where it is really needed (Design for simplicity; add complexity only where you must.)
When designing various information systems, I often say to myself “stop: it’s harder than it should be” and go back to the beginning in order to understand what went wrong. The complexity of the system is not so much the cost of support as the cost of development. The answer to the question of what consequences a change will entail for a sophisticated system will require much more time than a business requires. Step by step, the system dies and among programmers they begin to express more and more boldly the thoughts about a complete reworking of the entire product.
')
I wrote earlier about the KISS principle and “Occam's razor”, in an article about the principle “clarity is better than cleverness”. Therefore, I will present this article in the form of a digest of other people's thoughts on the topic of simplicity and complexity.
Antoine de Saint Exupery said on this occasion the most excellent thought, " As you can see, perfection is achieved not when there is nothing to add, but when nothing can be taken away ." Remember the times when a new iPhone appeared: banter on the topic “what the iPhone doesn’t have and my grandmother’s pensioner phone” was the leitmotif of all forums. Because in order to be good and in time, it was all superfluous. The Chinese, as we see, think exactly the opposite.
When adding
Perl has a couple of mottos attributed to Larry Wall. The first is “ There is more than one way to do this ” (There's More Than One Way To Do It. There is even a reduction for this - TMTOWTDI). The second is “ Simple things should be simple, and complex things should be possible ” (Easy Things should be possible). The situation when the developer cannot relatively quickly answer the question of the feasibility of improvement and at least roughly estimate the labor costs and the necessary changes should be alarming. So, now it’s not the developer who manages the system, but she to them ...
Particularly should strive for simplicity in data structures. Eric Raymond, in his book, Cathedral and Bazaar , uttered a very correct idea: " Good data structures and bad code work a little better than good code and bad data ." Tinkering with the system "anew" the main difficulty is often the data and the mistakes made in the design. Just last week, I interviewed a programmer who, in response to a question about the correct, in his view, variant of storing address information, offered to store everything in one field, sharing
Another expression on this subject is attributed to Ludwig Wittgeinstein , “ A good architect is different from a bad one in that the bad one is tempted, and the good one avoids him ”. It is the
A lot of complications occur at the level of product specification development, when the customer finally understands what he wanted at the very beginning (the second time he understands this when he sees the first prototype, and the third when everything has already been implemented). Complicating the specification is very simple - literally everything has to do with it. It will be very difficult to work on it. Therefore, it is necessary to follow the rule: the price of any change includes not only this change, but analysis of the impact and price of bookmarks on highly probable extensions (including removing this change if necessary). It is clear that with an increase in the number of requirements, the price of such changes increases, both in the project documentation and in the product. Therefore, as soon as possible, I recommend adding all non-key requirements that come in addition to the next stage in order to start the first as soon as possible in order to get the prototype and the first release as soon as possible. Let it be simple, albeit insufficiently functional, but ready for tests for performance, usability, reliability.
I will conclude today's article with the famous expression of Oscar Wilde , the confirmation of which I meet literally at every step: “ There is nothing difficult in life. That we are complex. Life is a simple thing, and in it what is simpler is the more correct . ”
| " Previously: the rule of composition | Continued: code savings rule " |
Source: https://habr.com/ru/post/103628/
All Articles