Controversial, but relevant design principles

In our company in the development process it is customary to adhere to a few simple principles. Perhaps, they may seem controversial to someone, to someone naive, but just like the calendar , which our IT director (aka paulig ) wrote about last year, these principles are the result of our own experience and mistakes. In addition, we believe that following them makes it possible to solve problems faster and more efficiently.

Why was this written if there are a lot of books on development methodologies (including extreme programming, scrum, tdd), on programming in general, and in particular, on how to feed cats and about the “ideal code”? There are many books, but unfortunately, developers do not like to read them. Well, okay, love, but not all. They have, they say, their own specifics. Quintessence is needed. And simpler, closer, clearer. That is why. And in life most often have to remember, or rather, do not forget, it is those listed below.

Looking at the page history in our corporate twiki, I noticed that the small list with explanations, on the basis of which this publication was made, began its existence in 2006 and was slowly added to 2011. Then for some reason died down. Maybe someone from the readers will have a desire to add something?

Simplicity

If the solution of the problem turns out to be too complicated, then with a probability of 99% the solution method is incorrect.
')

Unix way

If possible, the program should perform one action, but do it well.

Occam's razor

In addition to not multiplying the essence, we always remember the thesis “we will never need it”. And, most likely, it is not really needed.

Bike already exists

Before inventing your own solution, it would be nice to look around: maybe someone has already solved the problem and did it better than we want. Do not forget about the world of free software.

Replays

If the action is repeated more than six times, then it is time to automate this action in one way or another. Options: write a script, create a class, write a macro.

Why exactly six times? Because up to six attention to this is usually not paid.

Tests

Any implementation must begin with the implementation of tests.
That is, before you start writing a program, you need to think about how to test this program. And start testing. Even if there is no implementation of what is being tested. Tests will help to understand what to do and how, and what - no.

Podkustnye creeps

“Podkustnye vypolzni are born immediately. as the name suggests, they crawl out from under the bush. ”“ Radio Day ”, Quartet I and other participants of the performance.

Podkustnyh polluted does not happen. And you don’t even have to try to solve the problem __ the problem once. Just believe that this is impossible. but if you break it apart, the solution of the subtasks becomes quite real.

Time

Working more hours doesn’t mean more. Productivity and time management are completely opposite concepts.

Obvious

Do you think someone can read your mind? This is an erroneous judgment. Telepaths in our imperfect world can only be found in the mirror. Therefore, before you do something, based on your idea of ​​the awareness of others, you need to make sure that others are “in the know.” Or "in the subject."

That is, it is always necessary to inform colleagues about your vision of the project and its role in it. And then they themselves will not guess.

Shortlist

1. Simplicity
2. Unix way
3. Occam's razor
4. Bicycle exists
5. Replays - automate
6. First tests
7. There are no podkustvny
8. No need to work out time
9. Nobody knows how to read