Principles are eternal, practices are illusory

There is a big difference between principle and good practice.

Best practices are subjective and depend mainly on the context, while principles are eternal and universal.

After writing the article “The more I know, the less I know” ( English ), I received several emails stating that there are some practices that need to be followed absolutely in any software development process.
')
I have long wanted to write about the principles, and here the above fallacy made it clear to me that it is necessary to clearly understand the difference between principles and practices. We do not want to pour water from the bathroom with the child.

Let's look at some of the best practices.

To begin with, let's look at some of the best practices in software development, and then compare them with principles for a greater understanding of the idea.

One of the most popular practices is of course unit testing. I already wrote about my doubts ( English ) about the need to blindly follow the best practices, but whether we should follow them or not ( English ) is not what I want to say now.

Unit testing depends on context. What I mean by this is that everyone agrees that there is a set of circumstances that gives value to unit testing.

If you work in an environment where unit tests take a lot of time to complete, or you have a waterfall approach where you have a long list of what needs to be implemented with detailed requirements, then in these conditions, unit tests begin to lose their value.

But instead of arguing where unit tests have the lowest value, let's better talk about where they have the most value. In this matter, we will come together faster.

Unit testing has the greatest value in flexible methodologies, with rapid and frequent changes in the requirements for the product being developed and frequent refactoring. Also, its benefits increase when there is the possibility of really fast writing and executing tests, because this feedback facilitates the iterative process of writing tests, which is especially important in TDD.


There are a bunch of other good practices, such as commenting on code documentation or documenting with UML diagrams, but the context still plays a role in determining the value of these practices.

When most developers called variables and methods short names, then commenting on such code was important. Until agile practices became prevalent, it was critical to provide detailed requirements for the product prior to its development.

But most of the best practices are really good!

Yes, you are right, most of the best practices are really widely applicable and useful in a large number of contexts.

For example, it is considered good practice to use version control systems, and it is difficult to imagine a situation where it could harm.

Is this not a specific rule or principle?

No, it is still too specific to apply it in all cases and the fact that your code is in the version control system does not do anything to improve your product.

If you followed the best practices, but did not discover the principle underlying them, you would hardly have benefited from it.

The fact is that most of the best practices come from universal applicable principles that never change. Therefore, most of these practices and the best.

The problem is that the use of practices does not guarantee you the benefits of the principles underlying them.

More and more I meet teams that:

• Write unit tests
• Use continuous integration
• Use version control systems.
• Scrum rallies
• Practice pair programming
• Use IoC containers

But they benefit from it tending to zero. Just more headaches and unnecessary body movements. And the reason is simple ...

It is not the practice that is effective, but the principle underlying it.

Principles are everywhere. We meet them everywhere and always in our lives. You can not live a day, so as not to face 100 times with various principles that affect your life, such as the law of attraction.


Gravity is a great example for understanding principles. As far as we now know, this is a universal force that acts always and everywhere. It is impossible to avoid gravity, wherever you go, it will be there and will act on you.

Principles are like the laws of nature, only wider. Principles can rather be called the laws of reality. Maybe you can not even fully describe them or understand how they work, but they always work.

Take for example the "law of the harvest." Most people are familiar with this principle. In general, it sounds like:

-> What goes around reaps <-

How universal is this truth? Is it possible to avoid this principle? How often did you participate in a situation with this inevitable law?

Many best practices in software development are based on this principle. Think of the best practices that have made you make efforts to improve your product in its early stages.

TDD (or for ignorant Test Driven Development) is a really great practice. The basic principle of TDD is to introduce quality into the development process as early as possible, with the result that the final product is better.

If you apply TDD without understanding its principles, you simply simulate TDD without receiving any benefit.

If you cannot understand at any level that the meaning of TDD in sowing good grains, which you then reap later, you cannot write good tests.

There is nothing difficult in writing tests before a code, but there is something valuable in intentionally investing in the primary quality of a product, with the ultimate idea of ​​harvesting more from this investment in the right season.

That's why I love Bob Martin’s book Principles, Patterns and Agile Development Techniques in C # , he talks about the many principles in software development that are everlasting. Books like this and a book that I mentioned 10 times in my blog “How to make friends and influence people” are full of principles.

In fact, I now told you what Agile is. Thinking about the principles, you can read the Agile manifest . It was never considered as a detailed description of the development process or a list of best practices, rather as an admission of a set of principles that guide the development process.

So do not forget when you argue with someone about best practices or think whether to include any practice in your project, then if you do not understand the principle on which the practice is based, then no amount of rituals, procedures, dances with tambourines from this practice will not help you.

Source: agile.dzone.com/articles/principles-are-timeless-best
From the translator: sorry, publish in the hub "Translations" did not work, did not have the principle to the letter "K".