a little madness

A man needs a little madness, or else he never dares cut the rope and be free -Nikos Kazantzakis


Archive for July, 2009

Where I Program

If, like Andy Brice, you wonder what the workspaces of small software companies look like, then wonder no longer. If you’ve been following, you may remember that I live in London these days. More specifically, I’m currently in the Marylebone area (a short move from Baker Street), which is brilliant. Even better is having a view over a local park from my desk:

Zutubi London Office

Zutubi London Office

Moving from northern Sydney to London you do feel the lack of green, but the parks in this area make up for it (not least The Regent’s Park, which is a short stroll away). Having a pleasant outlook also makes it easier when you’re stuck inside most of the day.

Are You Running Your Software Project Like an Investment Bank?

Recent experience has shown a wee problem with the way investment banks incentivise1 their workforce. The so-called bonus culture encourages excessive risk-taking optimised for short-term gain. This suits the employee, who pockets a succession of massive bonuses before the bottom eventually falls out (and spectacularly). When the inevitable happens, said employee can take a year or two off, collecting rare South American reptiles (or whatever else takes their fancy), before returning at the beginning of the next bubble.

What has this got to do with software? Allow me to stretch to not one, but three analogies…

Lack of Feedback

The shifting of pain caused by the credit crunch is self-evident: around the world governments are propping up failing banks, and workers from unrelated industries are losing their jobs. The root problem is allowing people to create pain without them feeling the effects themselves. This lack of feedback allows people to optimise selfishly, consciously or unconsciously. Analogous situations arrive in software projects when developers are isolated from their downstream users. For example:

  • A setup which places responsibility for quality on a dedicated QA team, rather than across the whole project, allows developers to disclaim responsibility for quality issues. This in turn allows them to churn out high volumes of poor quality code without paying a toll for it. That is, until the day when the bubble bursts, and they realise they are encumbered with an unmaintainable pile of spaghetti which defies improvement.
  • Every layer placed between developers and their end users muffles critical feedback. Opportunities to make simple fixes that could vastly improve the user experience are missed, as the message never gets through all the layers. The users are stuck with the pain, and the developers remain blissfully ignorant.

The solution: shorten feedback loops wherever possible. Make feedback faster, easier, more visible and act on it.

Metric Abuse

Metrics are a wonderful and useful tool. Indeed, they can be an important type of the feedback called for above. But they also have a dark side: they can easily be abused to create flawed incentive systems.

Probably the worst abuse of metrics is trying to measure “productivity”. In investment banking, taking profit as productivity leads to long term issues due to unsustainable risk. This is analogous to measuring developer productivity by the quantity of code (or stories, or whatever) produced. This doesn’t take into account the quality of the resultant software, not just in terms of code quality, but other intangibles like the user experience. You might ship a lot of features, but eventually your software will become so buggy and complicated that people will stop using it. “No problem”, I hear you you say, “just use quality metrics too!”. But these exhibit the same issues: any indirect measurement is flawed, and ultimately leads to people optimising the metric rather than their productivity.

The solution: don’t pretend productivity is a number. Life just isn’t that simple: you need to pay attention to the bigger picture.

Technical Debt

Apologies for mixing my financial metaphors, but my final analogy to draw revolves around Technical Debt. Although we might recognise and acknowledge that short term wins can cost more in the long run, sometimes practicality dictates taking a short cut. In the real world we do need to make compromises, whether we like it or not. This gets out of hand, though, when we don’t acknowledge the debt we are building up. You can try, like the banks, to push your debt to the side – hiding it away in obscurity. But the debt is still there, and it’s not getting any easier to pay off.

The solution: if you take a short cut, acknowledge the debt you are creating. After the real-world crisis has passed, start paying it back immediately.

1 Bingo!