I bring to your attention a translation of the article " Simple Hickey " by Robert C. Martin (Uncle Bob).
Rich Hickey delivered an excellent lecture in Strange Loop entitled Simple, Easy. I highly recommend you spend an hour listening to it. This performance is worth every second.
There will be some things in this lecture that you disagree with. When this happens, stop and think - think seriously - do you really disagree. Perhaps you should not think that this is so.
For example, Rich says some seemingly dismissive things about TDD and Agile and Refactoring - the sacred cows of the Agile Community. If you are committed to this community, you can react negatively. Do not. Rich does not neglect practice. He neglects religion - recklessness - frivolity.
Rich compares unit tests with safety rails. Then he makes a very good point. He says that when you have an error, then this error passed your tests. And now what? You should now find the error. And if the system is not simple, it will not be easy. (Please note that I used the words here simply and easily. The beginning of Rich’s speech is connected with different definitions that these words have. I suggest you stop at this place and listen to the first ten minutes of his speech, and then return to this paragraph again.)
Rich emphasizes that sprinters run fast, but not for long. He then says that Agile "solved" this problem by simply firing the starting pistol again and again in quick succession. He smirks and the audience laughs. He then goes on to say that continuous sprint does not necessarily make systems simple, and simplicity is the key to speed.
Of course he is right. Martin Fowler spoke about this in his article “Flaccid Scrum”. And this is what many of us in the Agile community have expressed. Such short iterations without good technical practice do not lead to rapid development. Rather, it leads to a mess.
Rich laughs at the idea that a test suite will allow you to change the code. He says that tests are a safety net, nothing more. We TDDers know that a test suite is necessary if we want to fearlessly change the code. But Rich is right about safety net. A security system can help you simplify your system if it is already simple. But a security system under a large wad of dirt will have little help in unraveling the mess. Oh don't get me wrong. I need these tests! But the work will not be easy. (again this word).
Here's another talk from Rich: Hammock Driven Development, in which he encourages us to think, and not just write pieces and pieces of code.
So here it is. Rich is worried, and rightly so, that we have a complex culture. When a task is set for programmers, they run forward and write a lot of confusing code, using "simple" frameworks and tools, without giving the problem proper meaning. What we confuse lightness with simplicity. (For example, Rails is easy, but it's not easy.) His complaint about tests is that we used them to replace thoughts. Which is good for us, because we wrote tests, but in fact we did not spend enough time on the problem that it deserves. We did not simplify the problem. We just did what was easy.
So, in truth, the Agile community and the entire software community are infected with this disease. Too often, we do what is easy, due to what is simple. And so we make a mess. But this is not the value of agility now and never will be. And this, of course, is not the value of mastery of the software! Indeed, doing what is simple, unlike what is easy, is one of the defining characteristics of a software wizard.
In the end, I think Rich’s TDD perception is distorted by what he sees in the industry. Honestly, I think he missed some details. And I think he would understand that this practice would be as useful to him as to me. Not as a way to avoid reflection and throw yourself in a mess, but as a disciplined way to be detailed, careful and thoughtful.
Now ask yourself what TDD means to you. Is TDD the discipline you use to make things easy? Or is it a discipline that you use to be thoughtful, careful and not complicate?