Steve Freeman

Wait for a minute in.

This requires a lot of practice.

via http://centripetalnotion.com/

“Keyboads dirtier than a toilet” (BBC)

It justifies my view that eating lunch at the desk is uncivilised, and that pairing stations should have two keyboards.

Now that everything is USB, maybe we should just carry our own input devices and just plug in when wherever we’re working. Hmmm. Sounds like my dissertation, maybe I should have stuck with it…

I seem to be blog-stalking Keith again.

In his post on Creation under Constraints he uses a post from Andrew Binstock to write about the benefits of discipline on creativity. After all, is there anything more constrained than the form of a Rock’n'Roll song? Bartok had a thing about using the Golden Ratio to structure his work. Even in my misspent youth playing free jazz, the good musicians had an identifiable voice that implied form and structure.

Getting back to the point (there is one? ed.), the phrase You Ain’t Gonna Need It (YAGNI) often seems to be applied at the micro level by using primitive types: I’ll just use a String for this address, I can figure out whether I need a type later. Except that, later there are Strings all over the code, only some of which should be Addresses and, by the way, it turns out that I’ve assigned some company names (also String) to address fields by mistake.

String is about implementation, it’s not expressive in the domain of the code. And I’d double that claim for anything that involves templated collections, when there are three or more levels of nested angle brackets it’s time to turn back.

An alternative view, is to say: I need an Address, I’ll declare an empty type and add features as I discover the need. I don’t expect to need a getBytes() method on Address, but I might well need to ask it for its post code.

Over time, I’ve become more and more convinced of the value of declaring types for everything. I don’t observe this practice as much as I think I should, probably for the same reason I have too many fillings.

---

Incidentally, for a fine example of working under constraints, the Abelson and Sussman videos go for hours before they discover a need for mutable values.

There’s been quite a buzz in the narrow world that I inhabit about this recent interview with Donald Knuth. For us “TDDers”, the relevant quote is:

[…] the idea of immediate compilation and “unit tests” appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about. Nothing needs to be “mocked up.”

Keith has discussed this point nicely. Personally, in a scarily long time in software (which including tourism at some of the best research labs in the world), I know of a handful of people who can think very hard and then type in a working program of more than 3 lines.

In the meantime, I’m curiously chuffed that the concept of mocking appears to have entered the vocabulary of someone so far away.

As I said, I inhabit a very narrow world.

We’ve just sorted out the venue (after a couple of bumps along the way) for this year’s event. No details yet, but watch this space.

Joseph Pelrine and I are involved in (or is that “committed to”?) starting up a Narrative Inquiry project with the Agile Alliance under their Agile Narratives programme. This one will be done jointly with Cognitive Edge using the Cynefin approach, here’s their announcement.

I’ve started a Yahoo Group for people who are interested.

---

What is going on out there?

A proposal for a Narrative Inquiry project within the Agile Narratives Program

Introduction

How does the Agile Alliance find out what’s important to its members, and highlight interesting new ideas amongst all the noise? The activity of finding out is called Sense Making. This proposal is for an experiment to understand how well one approach to Sense Making works and can be applied to the Agile community.

The Agile world is changing as adoption by individuals and organisations grows rapidly. It used to be possible for individuals more or less to know what was going on, but the community has long been too large for that kind of personal network. How do Agile practitioners, novice and experienced, make sense of current practice in the discipline?

One technique is to use personal stories from the community, managed as semi-structured data, to support quantative analysis and to help understand individuals’ concrete experiences. The Agile Narratives Program has been investigating one approach to this technique. This proposal is to start a complementary project in collaboration with Cognitive Edge using their Cynefin methods and SenseMaker tools.

Proposal

We will set up a programme to gather and index brief stories from members of the community about their experiences of adopting and working with Agile software development practices.

Bootstrap. We will start with a session, run at the London eXtreme Tuesday Club, to gather “indexing” topics, questions that the storytellers themselves will use to categorise the stories that they contribute. Cognitive Edge will then set up an initial data-gathering site based on those questions. We can prompt for contributions within the XtC and various Agile groups on the internet to seed the contents of the database. We might also be able to use some of the content from the existing Agile Narratives database.

Pilot. We will run a pilot event at XP2008, based on this data, to trial techniques for gathering and analysing further stories, in the context of a public event. Dave Snowden (founder of Cognitive Edge) will be a keynote at that conference, which will help to attract participation. This pilot will test our approach and should provide enough initial data to experiment with quantative analysis.

First run. We will run activities at with Agile2008 to raise awareness of the program and to gather stories from the much larger group, based on the experiences from the Pilot. We might have enough data by then to attract attention with some early findings, or be able to show how the results change over the week.

Ongoing. Once the project is established, we intend to keep it active as a place to contribute and find stories about Agile practice “in the field”, about practitioners’ real experiences. From time to time, we can re-analyse the data to report trends and surprises.

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.

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!

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.

Two conferences back-to-back.

On Thursday 13th March, I’m chairing a track at QCon London called XpDay Sampler. The idea is to build on the long-running success of the XpDay and run some of our sessions for, we hope, a new audience. We think we have a pretty strong track, finishing with a panel session including Kent Beck—who’s never actually spoken at XpDay but he did turn up unannounced at the first one bringing Swiss chocolate.

On Tuesday 11th, Romilly Cocking and I will be running a new tutorial we’re developing with Nat Pryce on Test-Driven Development with Mock Objects, following on from a successful first run at the last XpDay.

Finally, from the 16th I’ll be at SPA presenting with Mike Hill a taster of our new Examples course, and with Michael Feathers and Meirion Morgan (a quant friend of mine) a very introductory workshop on using a functional language (OCaml) using financial derivatives for our examples.