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 development rules for Unix "according to Eric Raymond ", which, in my deepest conviction, can be extended to any other operating systems. I already talked in the first three parts about the rules of modularity , clarity , composition and  separation . Today it comes to the fifth rule - Rule 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 more difficult than it should be” and I return to the beginning to understand what went wrong. The complexity of the system is bad not so much the cost of support, but the cost of development. The answer to the question what consequences the change will entail for a complex system will require significantly more time than the business requires. Step by step, the system is dying, and among programmers, thoughts about the complete alteration of the entire product begin to express more and more boldly.

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 as a digest of other people's thoughts on the topic of simplicity and complexity.

Antoine de Saint Exupery said an excellent thought on this subject, “As you can see, perfection is achieved not when there is already nothing to add, but when nothing can be taken away . ” Remember the times when a new iPhone appeared: the banter on the topic “what an iPhone does not have and my grandmother’s pensioner phone” was the leitmotif of all the forums. Because in order to be good and in time, all this was superfluous. The Chinese, as we see, think exactly the opposite.

Adding something new to sufficient, each time ask yourself how much this will produce an effect, whether you were able to evaluate it, or just guesses. Especially in the second case, leave the opportunity then to "cut off" it painlessly.

There are a couple of mottos in Perl 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 possible ” (Easy things should be easy and hard things should be possible). The situation when the developer cannot answer the question about the feasibility of the revision relatively quickly and at least tentatively estimate the labor costs and necessary changes should be alarming. So, now it’s not the developer who manages the system, but it ...

He should especially strive for simplicity in data structures. Eric Raymond in the book “ Cathedral and Bazaar ” uttered a very correct idea: “ Good data structures and bad code work slightly better than good code and bad data". Remaking the system “over”, the main difficulty very often is precisely 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 opinion, option for storing address information, suggested storing everything in one field, separated by some rare symbol. All subsequent questions disappeared at once.

Another expression on this subject is attributed to Ludwig Wittgeinstein : “ A good architect differs from a bad one in that the bad one gives in to temptation, and the good one avoids it.” So in programming: if you want somethingadd, stop, write down on a piece of paper and continue to work as it worked. If you design the 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 development of the product specification, 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 is already implemented). To complicate the specification is very simple - literally everything has to do with it. It will be very difficult to work on it. Therefore, it is worthwhile to be guided by the rule: the price of any change includes not only this change, but the analysis of the effect and the price of bookmarking the 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 design documentation and in the product. Therefore, at the first opportunity, I recommend that all non-key requirements that come in addition be recommended to the next stage, so that the first one can begin as soon as possible, to get a prototype and first release as soon as possible. Let simple, albeit not sufficiently functional, but ready for testing for performance, usability, reliability.

I will end today's article with the famous expression of Oscar Wilde , whose confirmation I meet literally at every step: “ There is nothing complicated in life. That we are complicated. Life is a simple thing, and in it what is simpler, the more correct . ”

"  Earlier: composition rule

Continuation: rule of code saving  "