Okay, so, I’ve been a little grumpy lately.
But of course, it’s not enough to just shout at people who think TDD doesn’t work.
It must be a big weakness of our pedagogy that so many people feel that way. So I ask myself, what are we not teaching, or not teaching enough of, or not enough of us teaching?
Given the descriptions from the unfortunates who tried not-TDD under the guise of TDD, it seems clear we’ve under-emphasized the means by which the process detects flaws and forces code change.
(In one sentence, I’ll describe TDD as a process. You can go back all over this blog and http://anarchycreek.com to get details. The TDD process is a matter of deciding what to change, forcing that change using one or more microtests, and concurrently optimizing the design by using your sense of the new friction, coupling, and general infelicity of the code that works.)
Wait. There it is.
Codesense Is Critical
TDD was created *by* geeks of a very high caliber. But it was created *for* all geeks, of any caliber. The result is that whole swath’s of technique have been somewhat assumed, when such assumptions were ill-warranted. To be clear, many folks have contributed much wisdom, but that wisdom is insufficiently studied and taught.
I will tell you now, as I’ve said before in the context of advocating microtests and microsteps: TDD will not work without good codesense.
Codesense is the developer’s basic sense that a given chunk of code is or isn’t optimal.
It’s how we know we’re coding well or less well.
I say the word ‘optimal’ like we’re supposed to already know that that means. The fact is there are bazillions of definitions of code optimality. Many of them capture all or part of what I mean, but others capture little or nothing.
Codesense is like common sense in three ways:
- it’s incredibly difficult to teach;
- once learned it seems obvious;
- it’s noticeably uncommon.
Judgment Is The Keystone Of Codesense and of TDD
I’m gonna go off-track for a moment to make one really important point: there is no algorithm for measuring the goodness of code.
Converting codesense into mechanism is a mug’s game, but it’s been ridiculously common in the industry, and still is. There are dozens of applications you can download, buy, or liberate that purport to identify “code goodness” categorically. Some have great ideas, but they don’t really work.
If I could tell every developer — and consumer of developer services — in the world just one thing, it would be this: people write code, not computers, and that is because individual human judgment is required.
In software development, we are permanently, irrevocably, irremediably, and happily, dependent on individuals using their individual judgment.
Maybe the biggest consequence of this dependence: there are very few fixed rules in assessing code.
Codesense Changes Over Time
What rules we do have frequently change. Nothing anyone said ten years ago should be taken as for-granted truth. Nothing. The game changes too often for that.
To take a straightforward case: structured programming, and there are many many people in our field who were raised on structured programming, says that every method should have exactly one entrance and exactly one exit.
public int myMethod()
else if(thatCondition()) x=doThat();
else if(!thatOtherThing()) x=doTheOtherThing();
else if(popeWearsFunnyHat()) x=doVaticanThing();
The modern synthesis is different. Nowadays we’d write this code like so:
public int myMethod()
if(thisCondition()) return doThis();
if(thatCondition()) return doThat();
if(!thatOtherThing()) return doTheOtherThing();
if(popeWearsFunnyHat()) return doVaticanThing();
Is the difference important? I’ll re-use a sentence I wrote nearly ten years ago:
“To a professional, *everything* counts.”
So, this is my first blog about codesense, but I guarantee it won’t be my last. And now that we’ve met the creature in the abstract, let’s get down to brass tacks.
Codesense is hard to teach, but it’s not that hard to learn. It starts with heightening your sensitivity to code.
I can readily recommend all of these books:
It’s important to understand: I’m not telling you to do everything these guys tell you to do. It’s not about getting an instruction book.
I’m telling you to *think* and *observe* and *notice* the code you write and what happens to it.
What’s worth noticing? What’s worth changing? How might you change it? These books and others will help you get your mind open to codesense.
Once that happens, it’s time to start looking at your daily existence as a software geek. There is no substitute for this work. The folks above are top-notch writers and thinkers about programming. They can help you learn how to judge. But the judging will still be yours.
One last thought.
Start Today, With Pain.
Notice Every Pain Code Brings You