Sloth-driven development

Man - terribly lazy infection. No, well, I'm not about you, of course! What do you mean! I'm so, about myself. About 99% of humanity. But not about you, no. You decide for yourself. But those 99%, as it happened - terribly lazy. Someone denies it, someone puts up, someone fights. And personally it seems to me that this is the same integral feature of our species, such as, for example, two arms and two legs. You can be killed, that we have no wings or gills - and you can learn how to make good use of what we have. So it is with laziness. Why deny it? It should be used in full. And here, since we have something to do with IT, let's see how this is in our profession.


At first, the case was not important. If you look at the technologies that were in use a couple of decades ago, you will notice that they were all very demanding of man. In computers 30 years ago, I am most surprised not by their size or low productivity, but by how clever, accurate, responsible and competent the programmer of those years should have been. An extra hole on a punched card - and a day of work in a landfill. Reading Feynman’s stories about how they made calculations for the Manhattan project , I was amazed that these calculations were generally made. It seems to me now that it would be extremely difficult to find people with such strong will and responsibility. Leni was not the place. However, since there were few computers, and relatively many engineers, among them were worthy ones.

As time went. More and more people began to enter the profession. Where from? Of those 99%, about which I wrote at the beginning. Of us, of the lazy. In some cases, laziness immediately worked on the result - it led to simplification of interfaces, unification of protocols, throwing out unnecessary. In other cases, laziness led to the failure of projects. We had to solve something. And then software development methodologies began to appear.
')

From the overheard conversation in the smoking room

- Any development methodology is better than just “ordinary programming”!
-No, because if I call the methodology "to write code only at night naked under the moon in the woods on hemp", then it is no better than just "ordinary programming"

How many different things invented in this area! Here, for example, the idea of formal verification of written code. Well, cool! Take and prove mathematically that the code you created is perfect. Dream. Song. But where is it used today? In the rovers? In software pacemakers? Everything? Somewhere in one project out of a million. Well, why? And you take and imagine a programmer who, after writing his code, after successfully compiling it, running it, smoke test and testing by a tester, takes it and sits down to display a formal proof of the correctness of the code. Do you know many not so lazy? I am one person for several hundred of my fellow programmers. And “one acquaintance for a couple of hundred” is another result that is seriously above average.

Well, or here's the idea of ​​a waterfall . Good idea. But he, too, is getting rid of his own. Theorists say: "It does not withstand the current high dynamics and rapidly changing requirements." Ugh, rubbish. The thing is that under the "waterfall" lazy people could hide for months, for years and do nothing. Well, it was good to hide there, and at the exit - the failure of the project. Modern “flexible” methodologies are advertised as “convenient for programmers” and “responsive to today's realities.” Again - ugh. Just scram very quickly pulls the lazy people out of the holes, just pulls it out by the ears, puts it in the center of the room and directs all the searchlights at them. That's why it is popular.

But with regards to laziness, the interesting thing is TDD . She, in fact, comes from what I started this article with: all people are lazy. However, TDD managed to put this laziness at the service of humanity on an industrial scale. Look here.

Suppose you are programming without TDD. You immediately write the code. For example, some kind of function. In this case, you are lazy. You do not really think about the name of the function, the names of its arguments, you can forget to check the input values ​​or not catch some kind of exception. You can be sealed, or even make a fundamental mistake. And all this can be understood - you are trying to minimize the amount of your work, right now, at this very second. Yes, tomorrow you will get an error here. Or will not jump out. Or not you. In any case - it will be sometime later, then we will fight. Such thoughts discourage, allow you to write frank I get on. Well, what can you do? Minimizing effort.

Now let's say you program with TDD. You start by writing tests. At the same time, of course, you are also lazy (and nothing has changed!). But, attention: you are no longer lazy when writing production code, but when writing a test. In this case, here is what laziness will be expressed:

1. You will write a test as similar as possible to how your real code for testing functionalities will work. Well, that then it was possible. Well, or look, as in the documentation. And this is great - you will test exactly what you need, save time and get the documentation.
2. You will think, and how would you like to name the tested class, method, its arguments. No, you might think about it when writing this method. But we remember - there you will be lazy to think carefully about it, write something. But when writing tests, the object of your laziness is a test. You will try to make the test simple and understandable, and therefore the name of the methods being invoked, and the arguments passed to them will be as simple as possible, understandable, nothing superfluous and everything in the case. And the real code will also inherit these properties by the automaton.
3. Being lazy when writing tests is very easy. The test is usually not very large, it is very easy to copy / paste it and, replacing a couple of characters, turn it into a similar, but slightly different one. And then in another. But having already written all these tests - you will have nowhere to go, one way or another you will have to write code that passes through them.

Morality

Laziness has always been, is and will be. We can't just get rid of it forever. But we can control the direction of this laziness, make this laziness not harm, and benefit. Do not be lazy to be lazy!