In this latest in the DoubleDawg series, we take a big step forward, even though the refactoring is simple!

Previous DoubleDawgDare

Take a look at this sweet little snippet:

public void longFunction(int index)
{
	int currentMaxIndex;
	// ... some tricky preparation stuff before we
	//     can even de-ref index
	//     among other things, setting currentMaxIndex to a
	//     positive integer.
	if(index < 0 && index > currentMaxIndex)
	{
		// ... log the condition
		// ... undo all the prep
		// ... get outta here
		return;
	}
	// ... otherwise do cool things with the
	//     de-reffed index
}

That There, Kids, Is A Bug. They’re Good Eatin’

But we can say a little more than just that:

It’s not a typo: the majority of typos are caught by a compiler because they’re mis-spellings, but this one creates a legal word. In fact, it’s a legal word even in this very narrow context.

It’s not a misunderstood requirement: I think we can say with some confidence that the product owner has not told the developer to implement “an un-enterable state of computation”.

It’s not a noob issue: by the time one gets around to learning &&, one has pretty much also learned ||. They kinda go together.

It’s not a brilliant bug caused by the staggering complexity of this high-performance multi-threaded rocket-science domain: which is what my victim teams always claim are the only kind of bugs they get, so microtests won’t help them. (Sorry, do I sound bitter?)

Code/Coder Mismatches

That bug is a simple code/coder mismatch. I call these babies ‘mismatches’ for short:

The coder thought the typing said one thing,

but the code thought the typing said another.

The code is trivially wrong. That’s actually a requirement for mismatches. If it’s not obviously the wrong thing, then we’re moving into the rocket science excuse. (After all, there are no defects that aren’t caused by the code and the programmer disagreeing about what the code does.)

The overwhelming majority of fielded defects are mismatches like these. Off-by-one errors, inverted logic, wrong order of parameters, forgotten conditionals, and so on.

Driven Code Can’t Mismatch

In the TDD world, huge swathes of mismatches are caught instantly, before they even approach QA, let alone the actual field.

The only reason the branch displayed above exists at all, in TDD terms, is because some microtest forced it to be created.

See, it is interesting to us if some chunk of code has behavior that’s different in one combination of parameters than it is in another. In this case, the complexity of the failure case lends even more interest to us.

And what would that microtest do? It would pass a -1 index. The branch would not get exercised, and the assertions in the microtest would fail.

A Part Of TDD’s Magic Is That

TDD Sidesteps Mismatch Bugs

Thump Thump Thump Thump. Red Green Refactor Integrate.

Those of you who’ve experienced the Industrial Logic eLearning series have even heard me intone those words, with appropriate gravitas, as a voice-over. (It was my debut screencast, you know. Shouts out to my IL peeps!)

The Four-Beat Cycle

The microtesting cycle is absolutely fundamental, so much so I’m going to repeat the four parts, even though I’m sure everyone who’s reading this blog already knows them:

• RED: We write a microtest that fails because the code isn’t (yet) there to make it pass.
• GREEN: We put the code in that makes it pass.
• REFACTOR: We change the design until it is as simple and clear as we can make it.
• INTEGRATE: We commit our changes, including the new microtest(s), to the source vault.

Is Four Beats Enough?

No. And also, yes.

The four beats are an overarching structure. That structure can contain a thousand thousand variations.

In the clip below, the rather gifted jack of all trades, Ruben Blades, sings the lovely song Patria, which has a very fine lyric. The video is just a standard “pretend it’s fair use mp3 by having a video” video. Just close your eyes and listen to the rhythms. High quality sound system recommended.

So Why Does Rhythm Matter?

I don’t know. It just does.

The interwebs is a very large collection of tubes, and you can browse for days before you run out of either definitions of rhythm or explanations of its significance. I got tired.

Anyway, my best explanation is in the sounds above.

A Part Of TDD’s Magic Is That It Beats A Rhythm

(Extra credit: How does today’s magic, rhythm, relate
to yesterday’s magic, profluence. Show your work.)

When Harvard Business School conducted its massive diary-collating research, the somewhat startling conclusion was that workers like it when their work is part of a progress.

“Part of a progression” has another name: profluence. In literary circles, it means the stuff that flows forward in a literary work.

Flowing Forward

I don’t know what the last great novel-you-read is. I trust you had one. (If you don’t have one, stop reading blogs and geek-books and go find a great work of fiction.)

Do you remember the sense of excitement that came with it? The anticipation? The intense need to know what came next?

Profluence. Forward flowing.

Microtests Advance Development

Here, the case is subtle. After all, most everything a developer does is meant to advance development, hence the name.

But development here means progress.

When a geek runs a red-green-refactor-integrate cycle, things move forward. That movement, profluence, is a significant motivator for humans. I spoze if traditional processes are working for someone, they already supply it, but in weeks or months.

The TDD discipline creates profluence every single day, several times a day, for any number of days in a row.

A Part of TDD’s Magic: Building Profluence

I struggled for a while to come up with the right words for this one. Of all the magic, this is the one that almost everyone can understand, and almost everyone can at the same time underestimate its importance.

What Does “I Programmed All Day” Mean?

I asked that question here, and my answer looked more or less like this: I …

• typed in some code;
• drew some pictures;
• rigged up the debugger;
• ran the debugger;
• waited for the debugger;
• figured out how to set the breakpoint so I got the failure case;
• debugged an execution path for a while that wasn’t actually broken;
• accidentally stepped over the line of code instead of into it, *nine* times;
• read 50 times more code than I wrote;
• asked peers to look at a problem;
• got asked by peers to look at a problem;
• stared into space;
• threw some kind of something at other people;
• surfed the web looking for answers;
• surfed the web looking for cool pictures;
• and so on…

Do you see those six sentences in the middle that mention debugging? Uh-huh.

Debugging Is Expensive

It doesn’t really matter whether you are debugging via the most sophisticated of hardware board-testers, or you’re just using printf statements. (Oh, I should add “put print statements in a bunch of weird places to see if I was even triggering the execution path I thought I was.” I do that a lot. Don’t lie to me.)

Either way, it’s a tremendous amount of time spent on not doing the right stuff, I mean the stuff to exercise the bug, find it, and fix it.

Microtests Short-Circuit The Old Debugging Process

Microtests change debugging, in two different ways.

First, some of them go red when you thought what you were doing was safe/right. Having a bunch of microtests is like having a debugger that’s always on.

Second, they are a great way to capture the repeatability of a bug. If you find a defect, and you’re doing TDD, the first thing you do is write a microtest that exercises the defect. From that point forward, you’ll know exactly what to do to exercise the problem: run your tests.

Together, these two changes will soon enough have you making the TDD pledge: “I will feel mildly guilty about launching the debugger when I was programming.”

Part of TDD’s Magic Is That
TDD Directs Debugs

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

The answer is really the answers, because TDD, like most valuable techniques doesn’t actually work in just one single way. TDD is multifarious.

Here, then, is the first way: TDD reduces the mental scope of the developer.

Juggling Ideas For Fun And Profit

It’s been fifty-plus years since the famous paper by George Miller entitled The Magical Number Seven, Plus or Minus Two: Some Limits on our Capacity for Processing Information.

He identifies a first approximation of the bandwidth of human intellect. He says it’s about two and a half bits, i.e. somewhere between 5 and 9. By this number he means to refer to the number of independent concepts or symbols that a person can hold simultaneously. In fifty years, researchers have amplified and altered Miller’s actual number, but the long and the short of it is that we still think he was either outright correct or at least correct-ish. Five-to-nine works pretty well, actually.

I like to think of this five-to-nine with a juggling metaphor: some people can keep five ideas in the air at one time, and others can keep nine ideas in the air at one time, and most of us in between.

TDD Focuses The Mind

When I say that TDD reduces mental scope, I mean that it allows the developer to focus tightly on a single problem.

The experienced TDD-ist works one small problem at a time.

Working on just one problem works, because it obviates the need for thinking of the two other kinds of problem.

1. Problems you (or a teammate) already solved.
2. Problems you anticipate in the future.

Free’d by TDD to focus tightly, the developer is able to keep a problem to something involving less than our natural mental limits.

(Part of) TDD’s Magic: Reducing Scope

Planning theater is when we spend time pretending to plan, by:

• Starting with both ship day and the work list;
• Impressing the plebes with the severity of the deadline;
• Requiring reduced estimates without reduced work;
• Agreeing with a scheme that will never happen;

There is usually only one reason for a team to choose planning theater over plain old planning: someone powerful wishes the team to bless some ridiculous assessment that they’re now committed to.

Here’s the thing. The next time you start a session of planning theater, why not just cut to the chase?  Print out the centered text below and affix your team’s signature to it. After all, rushing through a planning theatre session will work exactly as well as leisurely strolling through one: Not at all.

Since No One Cares About

The Correlation Of This Plan

To Reality

We The Undersigned Hereby Bless It

[1] I am indebted to Seth Godin for a number of things, but just now I want to highlight one: his coinage of the phrase security theater to highlight the impressive-but-useless process of boarding an airplane. [Ed: Apparently, I'm not indebted to Godin as much as I thought.  :) Bruce Schneier http://www.schneier.com/ is the rightful coiner of the phrase "security theater".]

This is not some faux-eastern wisdom stirred into my usually rather more earthy mix of insight and obscenity.

What I’m getting at when I say “the code wants” is that there may be another form of the solution available than the one my respondent is using.

It is ridiculously easy to bind yourself to an approach before you’ve discovered that it’s right. Code written like this has a kind of forced-fit ugliness to it.

Finding yourself with:

• Lots of little if-statements?
• 5 or more passed-in parameters?
• commented ‘paragraphs’ of code?

All these things, and many others, besides, are the code’s way of wanting to be different.

Don’t Let Your Planned Solution

Block Your Discovered Solution

Imagine that you were installing solar panels on the roof.  The rig is a big frame, and a bunch of 6×6 solar-panel-ettes. On these, one side is flat and polished, and the other side has a long wire coming right out of the center. Skipping the installation instructions, as you do, presents no major difficulty. You put each little panel-ette in so it faces the same direction: the flat polished side goes to the front of the frame, toward the sun, and the dark center-wired part goes to the back.

When it comes to the wires coming out the back, we wire them together left to right, and we use wire-ties to gather them into a single ever-bigger cable, kinda like so:

Sweet, like a charm. But when you hook it up the output power seems low. In a random debugging impulse, you decide to glance at the installation manual. And it shows everything you did, except exactly backwards. The side that faces the sun is the side that has the wires coming out of it. The side that’s hidden to the sun is the flat polished side.

Imagine the sputtering you’ll emit.

What A Horrible Design!

Well, that’s the first interesting property. The wiring in your eye, receptors on one side, wires on the other, is exactly the design you just dissed. The most sensitive parts of the receptors — rods and cones — is the part that faces towards your brain, where, truth to tell, there is no light. The part that faces the light is the part with the wires coming out of it. The wires — nerves — come out the front.

Eh? Come out of the front?? That’s ridiculous! If that were true, looking at your diagram, there’d be a big hole in my vision, the place where that really fat cable runs out into my brain!

Yes.

A Hole In Your Vision

That’s the second interesting thing. If you have a big fat cable (of nerves) that comes out from the front of the receptors, then there must be a big fat hole where it comes out of the eye and back to the brain. And that would mean that you have a spot somewhere in your visual field where there’s a hole.

I originally was gonna explain the blind spot to you. This article would be approximately 17 pages longer. Instead, I want you to go play here, and when you’re done, come on back. I’m glad I was able to skip that part.

Your Brain Is A Scoundrel

I don’t wish to put too fine a point on it, but your brain lies to you. All the time. About a lot.

We like to think of ourselves as neutral receivers of data from the environment. Thinking that is what mad Tom Kuhn called living in a paradigm. But it just ain’t so. Every thing you perceive, as this example suggests, is already cooked. Processed. Not raw. Fiddled with. Unreliable. In many cases, wildly unreliable.

A Corner Case? An Optical Illusion?

“Sure, sometimes, my perceptions are fooled by clever pixel-manipulators, but they’re generally straight-up, correct, pixelated, and raw.”

No, actually, they’re not.  Over the last thirty years, neurologists and biologists have demonstrated time and again just how cooked our experience really is. It’s not just visual. It’s aural, it’s proprioceptive, it’s feel, it’s taste, it’s smell. Most shockingly of all, at least to me, is that the same stricture applies inside the brain. It’s ego, it’s dreams, it’s memory, it’s reasoning, it’s logic. It is everywhere.

I’m willing to prove that the extent of the cooking is tremendous, touching every thread of your experience, but not today.

Today, I want to trick you into asking yourself a question:

If I Don’t Trust My Brain, What Will I Trust?

It’s a silly question, for all practical purposes. It admits of a great many possible answers: read western philosophy for a host of them, from Descartes forward, all written very poorly.

The bottom line here is that we have no choice. Our experience is cooked heavily by complex systems that broadly and systematically compromise its reliability.  But, hey, what else can we do?

We Rely On The Unreliable

Everywhere.  Always.*

* If you want a corner case, the corner case is the rough-and-ready reliability of science. I’m just going to say that and leave it there.