The Visitor Effect

This is an amazing, remarkable and wonderful effect we have been using at work to achieve things all by ourselves that we couldn't achieve in five lifetimes if we had to achieve things all by ourselves. If that sounds confusing, it is.

The visitor effect is a little like "rubber duck debugging".

spray n wipe.jpg

We've noticed at work that there are some corners in our code or some processes, that only one person is fully "across". One person wrote it, maintains it, and takes care of it. No one else ever needs to worry about it and frankly, no one else would want to. These are bad things because the "lottery count" is 1.

The "lottery count" is exactly like the "under the bus" count, but not quite as grim; I'll describe the latter, then the former. The "under the bus" count on a project asks "how many people would need to be hit by a bus, before all crucial project knowledge would be lost?" and is often phrased like this: "But what if Rupert* is hit by a bus!?" to which Ingrid responds, "Then you can be certain I'll need an alibi." Because all this casual discussion of death and mayhem is a bit distasteful, particularly for Rupert, it's better to say "But what if Rupert wins the lottery and doesn't come back to work on Monday?" The lottery count, then, is a more generalizable mathematical treatise, resembling a knapsack problem that ponders, which minimal spanning subsets of workers are barred from forming lottery syndicates to avoid major risk to the project? But I digress.

The visitor effect proceeds like this:

"Hmm, Rupert is the only person who understands the SCLABE System. We'd better ask for someone else to work on it with him."

Ingrid volunteers. But we give Rupert some time to prepare. "In three weeks time, Ingrid will look after the SCLABE System for a few days." Rupert experiences a brief panic then launches into a flurry of activity, tidying up and improving the system in anticipation of Ingrid's scornful gaze. Rupert looks at his code with fresh eyes. "What is this doing here? Why is this so broken? How come this thing is still scattered over seven classes? Why is this coupled to that? What's with these warnings? Why is that test commented out? Why isn't that TODO: done?" and so on.

Two weeks later Ingrid finds she hasn't got time to take over from the SCLABE System. But already it's running at 300% efficiency over its old performance.

This is the visitor effect.

* Rupert, Ingrid, and SCLABE are characters introduced by Simon Harriyott in What?! Rupert can't leave! He's the only one who knows the SCLABE system!. Simon's disclaimer, which applies equally well here reads: "SCLABE is a fictional legacy system written in COBOL on an AS/400. Rupert is a fictional developer, whose resemblance to anyone you know is the whole point of this exercise."


My book "Choose Your First Product" is available now.

It gives you 4 easy steps to find and validate a humble product idea.

Learn more.

(By the way, I read every comment and often respond.)

Your comment, please?

Your Name
Your Url (optional)
Note: I may edit, reuse or delete your comment. Don't be mean.