Dave W. Smith

I had an “ahah” moment this afternoon while wrapping tests around some legacy Java code that lacked any. To create an instance of the class, I had to construct object graphs of “stunt doubles” to pass to the constructor. The doubles had to have just enough behavior to pass muster with private methods in the parent class that were invoked form the parent constructor. Getting an initial spike working took a lot of “let’s just pass null and see how far we get,” followed by hand-rolling mock objects.

When I could finally create an instance, I began attacking the class’s single instance method. By eyeball, its cyclometric complexity was about 40. Lots of branches to cover, and it was already late in the day.

That’s when I had the ahah!

By setting breakpoints on every statement in the method, running the tests in the debugger, and clearing each breakpoint as it was hit, I could get a quick checklist for what lines of code where still untested. This was a lot faster than generating a coverage report after every successful test run to show me which lines were still untested.

I’m sure this is an old trick, but it was new to me. (Possibly because, outside of Java, I rarely spent time in debuggers.)

And yes, I know that it’s really not that simple. This technique doesn’t account for things like zero-trip for loops, which often represent hidden branches. The hidden branches I had to note separately as I went. And yes, you really only need breakpoints on the first statement of each basic block, but that takes thinking, and the time that takes is easily canceled out by how fast it is to just put breakpoints on every line that’ll take one. Plus, stopping at each line once gives you a chance to notice little things, which can pay off when you’re working with legacy code.

I’ve been happy in the past with shirts that I’ve bought from REI. Their shirts are usually comfortable and sturdy, and look funky in a way that is still safe for corporate casual. But fashion is all about change, and sometimes change has unexpected collateral damage.

After a season of zippered and velcroed shirt pockets, the cool thing in outdoor-wear this season is to either omit the pocket altogether (huh?), or to stitch a separator line vertically through the chest pocket to form two separate partitions. I guess this is to make it harder for sunglasses to fall out, which could be a feature when dangling from a cliff or trying to outrun a bear. Unfortunately, for the urban programmer type this means a shirt pocket that is too narrow to hold that most essential piece of Agile equipment, the 3×5 index card.

Every so often a podcast comes along that’s worth several listenings. Today was number two for Nat Torkington’s “Design for the Future” talk from this year’s Webstock. Nat gives a history lesson that draws together the Crimean War, the Victorian internet (5 baud telegraph!), and Florence Nightengale (as an early proponent of reality-based medicine). He then looks at what those bits can teach us about current trends, looking in particular at the sad state of the news industry and at software development for cell phones. A thoughtful, informative, entertaining talk that I wish I’d been at in person. Fortunately, the audio quality is quite good.

I’ve been working my way randomly through the Webstock 08 recordings, and have been generally pleased with the quality of presentations. If you listen to technology podcasts, check these out. They’re a bit slow to download, but worth the wait.

In all of the discussion I’ve read about Google’s App Engine, I’ve rarely seen anyone call attention to the logo. That’s a shame. The App Engine logo is a brilliant piece of work.

I mean, look at that thing. Strap some stubby little wings on a big ol’ turbine engine, and get ready to go somewhere. What a great visual metaphor for the promise of programming against part of the Google infrastructure. And check out those understated colors. That is a logo that gets its point across without searing your eyeballs or resorting to smoke and mirrors.

Whoever designed the App Engine logo is due some major kudos.

A startup I worked for was recently acquired. Merger paperwork has been arriving in clumps. One document that invited my signature included the wording:

“You have reviewed and understand the escrow and indemnification provisions of Article VII of the Merger Agreement (attached hereto as Exhibit 1), …”

So, being in a responsible mood, I had a go at Exhibit 1, even though I’m way out of my depth, and am such a minor shareholder that were I to heave all of the paperwork into the trash, the merger would proceed without noticing my absence.

After slogging through nine narcolepsy-inducing pages of turgid legal prose, I found this little gem in the final paragraph:

“A decision, act, consent, or instruction of the Shareholder Representative, including an amendment, extension, or waiver of this Agreement pursuant to Section Error! Reference source not found, and Section Error! Reference source not found, hereof, shall constitute a decision …”

Now that’s I bit that I do understand.

I’ve seen teams “game” velocity, doing risky things (like letting unit testing slip and quality drop) to keep their velocity high. It didn’t occur to me that part of the problem might be terminology. Tim Ottinger’s “Velocity is Just Capacity” gave my thinking a serious nudge.

“Velocity” evokes speed and quickness. Speed and quickness are good. Speed and quickness win races and awards. A manager whose team has a high velocity is a winner. Recall Mike Cohn’s advice to alway append “billion” onto any velocity number that you give to a manager so that they can one-up their peers.

But consider the reframe: A team has a demonstrated “capacity” for taking on work. The prior iteration (or a weighted average of the past few iterations), establishes a Load line (AKA “Plimsoll line”) around the team. Load is a measure of capacity. It’s velocity as Agile uses the term, but without the baggage of evoking competition. Discussions about increasing capacity are subtley different from discussion about increasing speed. Tim lays it out nicely in his article. I think he’s on to something.

Is a terminology shift all we need to drive out bad velocity behavior? Sadly, no, but I think it would be step in a good direction.