Feed on

Did you ever see a half-dozen lines of code, stare at it fixedly, and say “What the hell is this about?”

If not, ¬†does your Mommy know you’re up late reading blogs by grandfatherly computer geeks?

Do You Turn On The Fritzenjammer First?

A particular case of this comes with operations that were intended to be used in a certain order that you don’t know.

Does GyrateFritzenjammer() come before you isolate the GranfalloonMeter, or after?

Never mind that the design might have been better in the first place. The first place was occupied by some grandfatherly computer geek who cashed in bigtime on Y2K and now lives on a mountain somewhere in Peru that he owns.

(Though, as a general rule, those guys go everywhere with a T3. If you could find the e-mail you could get in touch. He will regale you with the tales of when he worked on the Mercury launch, and repeat the astonishing, but now quite old, trope about the Apollo mission having less total computing power than a modern shower-head. Oh, plus, also, they always talk about the old forgotten languages, like Java and Cobol. Or worse, it’s a fat old grandfatherly Smalltalk geek, wearing that unique armor composed of equal parts righteousness, purity, and a smugness to light the winter sky. Why I never play paladins, yo.)

That’s Not The Worst Of It

The worst of it is when you first have that experience while reading the code you yourself wrote just two short weeks ago.

So, what is missing from that half-dozen line code fragment?

What’s missing is a sense of what the author wanted when that code was entered. It lacks information about what the coder meant the code to do. It lacks intent.

Even, comically, when that author was you.

Everyone, especially solo geeks, writes code that does not reveal the intent with which it was written. Everyone.

TDD Multiplies Intent

When you’re TDD’ing, you are writing not just the code, but also the code that exercises the code.

And of course, if I want to know whether it’s Fritzenjammer before Granfalloon or Granfalloon before Fritzenjammer or whether it’s both because the coder was in a generous mood, or whether it’s even never because you’re only supposed to do one or the other before proceeding, the microtests will reveal the coder’s intention.

Now, I’m not sure whether writing microtests must, of necessity, render pre-existing code intelligible, though that’s my belief.

I am sure, tho, that test-driving your development will shape new code into intention-revealing code.

The real TDD, I mean: writing microtests one at a time to force your code to change, will reveal your intent, sometimes, in spite of your intent.

Part of TDD’s Magic Is That
It Multiplies Intent

2 Responses to “How TDD Works Its Magic (2): Multiplying Intent”

  1. Angela Harms says:

    How is it that even when you’re writing about technical practices, it’s poetry?

  2. […] more advanced, sneaky design mechanisms behind it are covered (for the advanced reader) here and here and here and […]

Leave a Reply

AWSOM Powered