I’ve just heard from Julie Meyer that Richard Duvall, the founder of Zopa, passed away earlier this week.

I met Richard for the first some years ago, while he was at Egg; more recently, via Julie, we met a few times while he was busy dreaming up Zopa, getting it funded and launching it.

Earlier this year we were both on the same small panel at Ariadne’s 5th Anniversary celebration, looking at Building Society For the 21st Century. In fact the kernel for this blog was written for that occasion.

Richard was one of the people who really got the power of the Web and P2P, and followed his dreams with his inimitable boundless energy. He didn’t just follow his dreams, he made them happen. Effervescent and charming, he was a pleasure to be with.

It’s normal to feel sad when someone close to you passes away. I didn’t know Richard that well, yet I feel really sad. That was the kind of guy Richard was. My condolences to those he leaves behind.

Bruce Schneier has written an interesting piece on how form follows function in any architecture, be it physical or electronic. My thanks to Kevin for pointing it out to me, and to Cory for making sure I didn’t forget about it …. I’ve been rushed off my feet lately….

Schneier’s arguments are simple, brought to life with eloquent examples and anecdotes:

• [Security-driven] changes were expensive. The problem is that architecture tends toward permanence, while security threats change much faster. Something that seemed a good idea when a building was designed might make little sense a century — or even a decade — later. But by then it’s hard to undo those architectural decisions.
• The same thing can be seen in cyberspace as well. In his book, Code and Other Laws of Cyberspace, Lawrence Lessig describes how decisions about technological infrastructure — the architecture of the internet — become embedded and then impracticable to change. Whether it’s technologies to prevent file copying, limit anonymity, record our digital habits for later investigation or reduce interoperability and strengthen monopoly positions, once technologies based on these security concerns become standard it will take decades to undo them.
• It’s dangerously shortsighted to make architectural decisions based on the threat of the moment without regard to the long-term consequences of those decisions.

All this made me think of the QWERTY keyboard. I grew up in a journalist family, with typewriters (the old Remington heavy-enought-to-give-you-a-hernia kind) outnumbering flowerpots at home. And when I first visited our printing press (I must have been nine at the time) I was quite surprised to see an ETAOIN SHRDLU keyboard. And my father explained to me that the QWERTY layout was designed to ensure that adjacent typebars didn’t jam, by separating high-frequency letters; that the layout had the additional “benefit” of slowing typing speeds down as a result. The linotype keyboard, on the other hand, was designed for speed, and therefore followed letter frequency distributions.

Form follows function. Just look how long QWERTY’s lasted. [An aside: It’s always amused me that the longest word you can form using the letters of the first line of the QWERTY keyboard is …. TYPEWRITER. What an unintended consequence. or was it? Maybe Grassy Knoll designed it]

We live in a world of many many cyber threats, some real, many perceived. I like the points that Schneier and Lessig make, particularly the pace-of-change one. There is always a temptation to take corrective action against security threats, both real and perceived; it is best to avoid that temptation altogether; but if we do give in, what we must ensure is that the corrective actions we take are designed to be as temporary as the threats; that we take care to make the response easily reversible, dismantlable, removable.

Imagine what would have happened if the recent ban on liquids on airplanes was enacted as law. Stupider things have been known to happen. In fact some part of me is actually surprised that the No Liquids rule didn’t become law.

Imagine what we’ve been doing to ourselves in building walls around our own information, within our own information. Actually paying people to build the walls, then paying people to drill through them, then paying people to fill the holes in…..

Now they know how many holes it takes to fill the Albert Hall.

Let’s keep those paths unpolluted.

For most of my adult life, I’ve been bemused, perplexed, sometimes irritated and occasionally completely taken aback by the error messages spewed out by the applications we build and use. Over the last twenty-five years or so, I’ve watched them improve, but at speeds that make glaciers look agile.

Today, while looking at technorati, I saw this:

Something is wrong! We know about it, and are working furiously to fix it. Please check back later and probably everything will be back up and running.

Great stuff. You may not think it’s perfect, given that it doesn’t actually say how long it will take to get fixed. But I like it. It is open, conversational, simple, honest and brief. I tend to think that the uncertainty implied in the message is actually a good thing; it made me think … could we expect to see error messages that are Agile in nature, improving by iteration as better information emerges/is discovered?

Who knows, this may be a leading indicator of the paradigm shift taking place in the applications and services space today.
My thanks to all at Technorati.

James Governor pointed me at this Kathy Sierra post before I’d trundled my way there (Thanks, James!).

The picture below says it all:

Kathy’s one of those people who creates extreme reactions amongst her readers, and I’ve seen raging arguments about some of her earlier posts. I can’t help but feel that at least some of the reactions are because she touches raw nerves. Which is why I love reading her stuff.
Three quotes stand out for me:

“If that person shakes us up, gets us to rethink, creates a little tension, well that’s a Good Thing”, the CEO says. riiiiiiiiiight. While I believe most CEOs do think this way, wow, that attitude reverses itself quite dramatically the futher you reach down the org chart. There’s a canyon-sized gap between what company heads say they want (brave, bold, innovative) and what their own middle management seems to prefer (yes-men, worker bees, team players). “

The management-middle management gap/reversion is something that has been commented on in depth before, and is by itself nothing new. What makes it new is that we have three new(ish, anyway) factors acting on the enterprise: a real war for talent; a real move from hierarchy to network; a real battle between professions as historical lines continue to blur. On to quote 2:

Of course some argue that exuberance on the job is not necessarily a good thing. That too much passion leads to problems. I say BS on that one. Real passion means you love the profession, the craft, the domain you’re in.

And I guess this is where the problem becomes more acute, as Abbott’s System of Professions evolves into its not-so-subtle conflicts. No single profession has an inalienable right to passionate people; middle management tends to be full of “professional” people; the passion for their profession creates considerable conflict, and can result in their looking for robotic slaves out of sheer frustration. And so to quote 3:

If you knock out exuberance, you knock out curiosity, and curiosity is the single most important attribute in a world that requires continuous learning and unlearning just to keep up. If we knock out their exuberance, we’ve also killed their desire to learn, grow, adapt, innovate, and care. So why do we do it?

Maybe we do it because we can’t find a way out of the professional conflicts and tensions Abbott refers to.
All is not lost. Kathy herself provides the answer, as much in her blog as in her post. Create passionate users.
We need to find a way to unite the professions. And there is a way. We’re just not very good at it, and keep getting in our own way.

Don’t focus on the profession. Don’t even focus on the firm. Focus on the customer. Focus on the customer. Focus on the customer.

A firm that unites around the customer unites all it does.  And becomes a formidable force.

My two previous posts, looking at the reasons for deviance between management and engineer views of projects, attracted a number of comments, primarily in two camps. One camp spoke of Management-in-Denial, going into the reasons and contexts why an enterprise would behave that way, travelling into shareholder-versus-customer expectations along the way. A second camp looked orthogonally at the same shareholder-versus-customer contention, suggesting that the expectations diverged right at the start, and that we need to get better at reducing that initial divergence by concentrating on pragmatic realities. The arguments then morphed into a classic marketing-versus-engineering debate, what we used to call vapourware or markitecture or, more recently, software-by-powerpoint.

It is hard to summarise a series of comments, you can’t edit snowballs. My apologies to any and all who feel I’ve misrepresented the arguments. If you want to know what they really said, read the comments.

I get the feeling that both camps concentrate on what happens after fan and excrement are in simultaneous play, rather than in the prevention of said occurrence.

I’ve had to manage projects in some form or shape for a couple of decades now, and so far nobody in management has ever asked me to lie, even if I’ve been that “management”. Sometimes I’ve been unhappy with the techniques used to present “reality”. Sometimes I’ve been unhappy with late changes to schedules and deliveries presented to me as a fait accompli. And sometimes we’ve just got it wrong. But it hasn’t been about lying or being in denial.

How can we get better? Here are some personal musings:

1. Let the deadline influence the design
When you ask someone to do something, one of the design criteria, an important one, is time. Once you agree on time, you can negotiate the functionality and performance characteristics of the deliverable. Often you have to negotiate with a set of “incomplete contracts” but that’s life. Emotion can be taken out of the negotiating process; agile techniques can be used to learn more about detail aspects of functions and performance; there is a continuous improvement process explicit in all this, and sometimes it results in a continuous migration process, when you have yesterday, today and tomorrow systems in parallel. Time-boxing and time-placing techniques are based on this, yet for some reason get little airplay.

How come everyone got ready for things like EMU and Year 2000 and Sarbanes-Oxley and all that jazz? Because there were two projects in each case. One did the paperwork. One did the real work. The ones that did the real work knew that the dates couldn’t change, so they negotiated on the What and the How rather than the By When. Which brings me to my second point.

2. Get the signal-to-noise ratio right

More than once, I’ve been involved in projects where the governance mechanism is larger than the project team, and where the pressure placed by such mechanisms creates more paperwork than code. This does not create a divergence between management and engineer; it’s fairer to say there are two projects, one producing paper and one producing code. And sometimes there is only one team having to do both, with predictable results.

As long as we have an Armaggedon approaching for the battle between professions, and as long as organisations haven’t completed their painful trip from hierarchy to network, we’re going to have intermediaries. And there is a price to pay for having them. The only solutions I can see are twofold: One, try and make the doer-to-checker ratio an integral part of the reporting pack, so that the cost becomes visible. Two, use the remaining checkers wisely, they can help in many ways. Which brings me to my third point.

3. Pass ownership to the real customer as soon as possible

We use terms like fast iteration, early testing, agile development, fail-fast, whatever. Hitherto I’d been worried about the tension between such approaches and the classical waterfall or cascade approaches. But the more I think about it, the more I feel that the approach-conflict is but a symptom. The root cause is a blame culture. Which sadly pervades too many organisations. So what we need to do is to find ways of reducing the impact of this blame culture. As far as I can make out, the best (perhaps the only) solution is to place something that works in the hands of the real customer, that can be used to create or derive value. Once you do that, all the dynamics change. Even if the value is marginal to begin with. Which brings me to my final point.

4. Get legacy skin into the game as soon as possible

Don’t talk parallel run. Don’t talk big bang switchover. Carry a big stick, move low-volatility information from Old to New as soon as humanly possible. Expose what you’ve done to the customer, and soon the old will atrophy and the new will thrive. [Note: There is an exception to this, an important one. Sometimes you get involved in building systems that are expected to do precisely what the ones they are meant to replace do in the first place. To the letter. No point getting legacy skin into this game, the customer doesn’t want the system. Get out quick.]