Stupidity considered harmful
18 Apr 2013 » Giacomo TesioDISCLAIMER
With this post, I join the “IWannaBeDijkstra club”, in the vain hope to end it.
I’m not Edsger Dijkstra. Neither are you. Live with it. ;-)
What’s harmful, now?
Recently, I’ve been caught by an interesting debate with a few very smart guys: Arialdo Martini, Dan North, Alberto Brandolini and Uberto Barbini among others.
Everything started with a tweet about code coverage considered harmful and a (casually) related thread started by Fabio Sogni in the italian DDD mailing list, that touched topics like the TDD definition, the meaning of code coverage, how they related to DDD and much more.
These days, code coverage is considered harmful.
If you carefully read the Pearson’s article, you will rapidly understand that all the issues proposed are related to either poor developers or poor architects/team leaders. Indeed, today, even Pearson changed his mind.
But why smart people get trapped with these sort of dumb, absolute, assertions?
Buzzwords Driven Development
The problem is the need for buzzwords, to exploit a bug of market.
A long time ago, far, far away, in a world dominated by monsters named Rose and RUP, a few fellow programmers, tried to address a weird, over-complicated development process with a few well defined practices from good sense. They lost some battle, but they won the war.
Now… Agile is the new RUP.
But back in those days, the most disruptive innovation was TDD: Test Driven Development.
Designed to avoid needless abstractions, TDD simply demanded writing tests before.
First. Before everything else. Even design had to emerge from tests and refactorings.
Indeed, one of our heroes once stated:
The act of writing a unit test is more an act of design than of verification.
Unfortunately, evolving from A.S.S. to Master Agile Software Craftsman, he forgot the why.
Don’t get me wrong: the Pragmatics of TDD is a valuable article, very useful and smart.
The only bug there is the title: they are not pragmatics of TDD, they are pragmatics of TDC.
(the only… apart setters! :-D)
TDC, what?
No, it’s not a new buzzword, just an acronym.
Robert Martin states:
TDD is a discipline for programmers like double-entry bookkeeping is for accountants or sterile procedure is for surgeons.
Right. It’s the discipline of writing tests before design, to avoid any needless abstraction. Plain simple!
Such discipline is required in some cases and it’s not in others. And indeed he states that he doesn’t practice TDD every times. He knows that he doesn’t need that tool and he avoids its use.
The point, however, is that you cannot partially apply TDD. TDD is for whole software artifacts, not just whole classes or methods. Indeed, the design can have a single source: either tests (strictly avoiding needless abstractions) or something else (when the needless abstractions are not your worse enemy).
Thus Martin is talking about the pragmatics of TDC: Test Driven Coding.
A different and extremely valuable tool!
But it’s incredible that he didn’t realized the deep difference.
Deep difference?
TDC is a different thing from TDD.
You draft the design and then you start with Green-Red-Refactor iteractions. Perfect. Very useful!
But you can’t call this practice TDD, or you lose the proper term to denote the original tool!
And TDD (the true one) is a valuable tool, whenever your worse concern is to prevent needless abstractions.
That, let me say, is quite rare! TDD, is useful in rare cases! But when useful, it’s strategic!
TDC is a totally different beast, useful in much more common scenarios: tests drive just the coding.
Some coding, at least. And this is perfectly fine. TDC can be partially applied to any software component.
Unfortunatly, most of those who claim to do TDD, do TDC instead. But they don’t want to be blamed as “casual testers”, thus they replace a letter in their resumes and their corporate brochures.
It’s not lying… it’s marketing, stupid!
But marketing is not for poor programmers like me, that despite manifestos, have to get the job done properly. I need a precise technical language to work with.
For example, those who state that TDD is compatible with DDD, probably haven’t ever done neither.
DDD is compatible with TDC (or, if you wanna use a cool buzzword, it is compatible with Outside-In TDD).
Back to code coverage
Is code coverage harmful, or not?
Guys, it’s a tool! A set of tools, actually.
Thus:
- if you are doing TDD, full code coverage is a useful feedback during development: if your CI breaks when you push uncovered code, you know that an hated, needless abstraction has poisoned your code.
(and if the converse isn’t true for your company, you should change your hiring techniques); - if you are doing TDC, sometimes it’s useful too: for example when you have to code higher level abstractions or valuable core domains. Having the CI that breaks on partial code coverage works as a sort of sword of Damocles that forces developers to carefully review code. A lot of times.
(again, if such expensive reviews do not provide the value that they cost, you should change your hiring techniques) - if you are doing TDC and you don’t need the quality that comes from such reviews, you should not measure any kind of coverage!
A few things worth noting here:
- aiming for high coverage (97%, 98%, 99%…) is a pointless waste of money.
- a full (100%) coverage can just ensure a minimal and unmeasured quality, not perfection. That’s obvious but tons of people complains about the bugs that full coverage can’t avoid.
So let me say this loudly: you still need testers and a brain!
Stupidity considered harmful
Stupidity is harmful. Like guns.
And like guns, stupidity feeds tons of people.
You can love your tools. But if you marry a tool, any tool, you are a stupid.
You should not be in the position of taking decisions.
If you always use TDD (or DDD or TDC or code coverage or anything else) despite of the project’s requirements, you are a dangerous mono-state automaton.
Specularly, if you refuse TDD (or DDD or TDC or code coverage or anything else) despite the actual value that such tool would provide in your specific case, you are wasting money just to hide your ignorance.
Still, you are not the disease, you are the symptom.
What is harmful here, is the stupidity of those who hired you, recruiting buzzwords.