Stephen Freeman Rotating Header Image

March, 2008:

Suddenly I've become less sympathetic to non-technical managment

I bumped into an old colleague recently who told me her tale of woe.

She’d been consulting for a while with a small business that provides quite a successful online service. The company had been bought out and, for a while, she improved their naive development practices while coping with complexities such as a new CTO who lived abroad and regularly dropped out of contact. In the end, she moved on to a new contract.

Sometime later, the CEO got in touch. He’d backed off some of his worst ideas, dropped some of the management and, eventually, hired her back as CTO. Good news.

On her first day, the lead developer threatened to quit unless he was allowed to start a proposed rewrite that day, another developer joined the mutiny. The CEO phoned after lunch and, with deepest regret, her tenure was over. The thing to remember about this situation is that the development team were mainly hired fresh out of college and only know this one company, whereas my colleague has lots of experience and is a name in the field. In her view, the codebase is bad, but not beyond rescue. My guess is that the company will burn a lot of cash on version 2 while its customers get fed up waiting for new features or patches to a neglected version 1. It’s a very high risk strategy for a small company.

How could the CEO fall for this? Presumably he knows a lot about the business the company services, but he has no background in the mechanics of what makes his product work. He has no instinct for when the developers, with the best of intentions, are getting carried away. So he’s taken what looks like the lower risk strategy, keep the people who got them this far, when in practice it’s the opposite. He’s also shown that he’s hostage to his developers which, much as I want to stand up for the underdog, is not a safe policy for either side. If he has any survival instincts at all, he’ll be looking for alternatives. Version 2 had better be a winner.

Update: Thinking further, I think it might even be worse, since the CEO didn’t see this coming, he hired a CTO without knowing how various core people would react and he didn’t have enough of their respect to make them listen. This is in a O(30) person company, not a mega-corp.

Suddenly I've become more sympathetic to non-technical management

My son has discovered Pokemon cards and now all I hear about is “Look, this one’s got a Damage of 7 and an Energy of 10.”

“Really? You don’t say.”

I have no idea what he’s talking about and it all seems overpriced.

That said, there’s one important difference, which is that my professional effectiveness doesn’t depend on what he’s doing with his cards (unless I’m really confused), so I have a slightly better excuse.


Here’s an example from the official Pokemon site:

Put Dialga LV.X (Great Encounters, 105/106) onto your Active Dialga and hold onto your seat as the Temporal Pokémon wreaks havoc on the game. The Time Skip Poké-Power on Dialga LV.X gives you the option to have your opponent flip two coins. If both are heads, your turn ends. If both are tails, your opponent’s next turn will end after he or she draws a card. Before using Time Skip, perform all other actions except attacking just in case you lose the coin flips. In addition to this time-altering Poké-Power, Dialga LV.X can dish out 80 damage with its Metal Flash attack. Dialga LV.X can’t use Metal Flash two turns in a row, but don’t forget that on your next turn you can use any attack, Poké-Power, or Poké-Body from its previous level!

Programming, it's really about language

Yesterday, during the XpDay Sampler track at QCon, Keith Braithwaite presented the latest version of his talk on measuring the characteristics of Test-Driven code. Very briefly, many natural phenomena follow a power law distribution (read the slides for more explanation), in spoken language this is usually known as Zipf’s Law. Keith found that tracking the number of methods in a code base for each level of cyclomatic complexity looks like such a power law distribution where the code has comprehensive unit tests, and in practice all the conforming examples were written Test-First; trust a physicist to notice this. This matters because low-complexity methods contain many fewer mistakes.

Keith used jMock as his example of code at the “good” end of the scale (thanks Keith) and, as he was showing some examples of its implementation, it struck me that a great many of those small, low complexity methods were syntactic sugar, they were there to attach a meaningful name to a little piece of code. We put a great deal of emphasis in our coding style on readability, on teasing out concepts and expressing them directly in code and trying to minimize the accidental noise from the language; we don’t always succeed, but that’s what we’re trying to do.

Is this why our code conforms to Zipf’s Law, because we’re trying to think in terms of language and expression, rather than in terms of procedures? Hmmmm.


The other question about Keith’s discovery is that it doesn’t yet say anything about causality. The first conclusion one might come to is that Test-Driving code leads to power-law structure, but I’ve seen TDD code that definitely does not have that characteristic. An alternative explanation might be that the sort of people who write that sort of code were amongst the first to be drawn to TDD, and that maybe TDD encourages the trend if you’re already mostly there. I’m not sure what an appropriate experiment would be, perhaps mining some old code that the TDDers wrote before they learned the practice? There are just too many variables.