Exploration Through Example

No.

.

.

.

.

.

Oh, OK.

@ctford asks:

@marick Have you blogged anywhere about with-redefs [a Clojure function used for mocking] and how it relates to mocking private fields in OO? I’d be interested in your thoughts.

@marick My concern is whether by using a test mechanism that prod code can’t exploit, am I reducing some of the design benefits of TDD?

——–

In order to design, the designer must find words (abstractions, if you wish) that give her leverage when thinking about the code.

In order for that leverage to carry over to writing and later changing the code, those words have to appear in it. Most importantly for a language like Clojure, verbs have to be reified as functions.

Testing makes design rigorous by forcing it to be concrete along a different dimension than coding (dynamic rather than static). Tests should therefore have executable (mockable) access to reified verbs.

A programmer using a function may need a conceptual understanding of those verbs, but does not need direct access.

Therefore the reified verbs may be marked private - but only if the tests have a way to evade that. (That is, the need to do the right thing with testing trumps the desire to prevent a future programmer from doing the wrong thing.)

In practice, I’ve found it mildly helpful to add a “testable” access level to public/private. That divides a chunk o’ code into (1) functions of interest to normal users of the code, (2) functions those users don’t need to care about, but that are important for understanding the idea behind the code, and (3) functions that are just a coding convenience.

I’ll be giving a keynote at ACCU 2013 on this topic: “Cheating Decline: Acting now to let you program well for a really long time”.

(Any resemblance to my own looming decrepitude is entirely non-coincidental.)

My premise is, roughly, this:

• We know that age causes cognitive decline. There’s some evidence that it begins well before a typical person’s working life is over.

• Programming, like mathematics, seems to be a field where that cognitive decline hits hard and relatively early. (There are all sorts of caveats around that statement, but let’s leave them for the talk.) Old programmers are thought not able to keep up with young programmers, to be wedded to old solutions to new problems, to be [fill in your stereotype here].

• Nevertheless, some old programmers notably defy this trend. Some are superstars who (unexpectedly) didn’t burn out young. Some weren’t superstars, just good, solid, eminently employable programmers when they were young, who (unexpectedly) turned out to still be good, solid, eminently employable programmers today (once they get past the prejudice).

• What’s special about those who smash the stereotype vs. those who reinforce it?

To answer the last question, I want to reach out to self-identified young programmers. If you believe you know someone who’s a stereotype smasher, I’d like to:

1. … interview you about what’s special about that older programmer (with attention focused on behaviors and habits rather than innate qualities).

2. … interview the older programmer and invite him or her to talk about the same topic.

If you are willing to participate, mail me.