Amazingly, some people aren’t motivated by efficiency

Staggering though it may be, it turns out that people are different. It also turns out that certain kinds of people are different to other kinds of people. And a corollary of this is that people who aren’t software engineers tend to have a different perspective to those who are.

For example, I spend a lot of my time trying to maximise our efficiency. Maybe this is because I’m a techie kind of person; I see the same motivation among the project managers, developers, and others in our software team. But very often we face the prospect of having to start a piece of work without having all the details available to finish the job. Maybe we’re waiting for information from a third party, maybe the visual design isn’t complete, maybe a decision still needs to be made by people elsewhere in the organisation. Whatever it is, we’re faced with the prospect of starting a piece of work knowing that we may not be able to complete it without an interruption.

We built the car very efficiently...This is clearly going to be frustrating to my techie, left-brained approach to life. It undermines my efforts to be efficient, organised, anally retentive, and generally less fun at parties.

I know it would frustrate others, too. Agile advocate Simon Baker recently railled against organisations that didn’t make product owners sufficiently available to provide the relevant feedback and information. He wrote

If the project is vital to the business, then the company can always find a way to provide a full-time and colocated Product Owner. If they say they can’t, it really means they won’t. Quite simply, they’re not prepared to do what is necessary to achieve it, and frankly, if they’re not going to take the project seriously why should you?

Ouch. I’ve felt the pain that Simon felt when he wrote those words, but we shouldn’t rush to make harsh judgements on business experts who are facing pressures of their own.

We software people can talk all we want about our methodologies, but sometimes we need to wake up to the cold, wet slap of reality. The fact is software development is not the be-all and end-all of most businesses — far less is efficient software development methodologies. Sometimes it’s more important to be working on the most important thing inefficiently than it is to be working on the second-most important thing efficiently.

At Guardian Unlimited we motivate ourselves by measuring velocity — the number of units of work we complete in a given period. But if we’re not careful we can focus on that too much and be in danger of missing the bigger picture.

Some time ago I was speaking to one of our internal customers, explaining why developers pushed back on incomplete specifications, and the motivation of being efficient and achieving target velocity. “I don’t give a stuff about velocity,” she said, “I just want the thing built.” The point is well taken. Sometimes we need to remember what the word “customer” means.

Anti-features

Sometimes you can trust too much. Wherever I’ve worked I’ve been involved in a few examples where we listened to the customer, trusted them to know what they wanted, given it to them, and they’ve regretted it. We have delivered anti-features.

A lamp with slightly too many featuresMost recently at Guardian Unlimited our (previous) homepage had clever layout rules whose logic sometimes overrode the content that editors entered. The result was that editors were often confused that the page didn’t render according to what they had put in the system. The clever layout rules had been devised by close collaboration with the original editors and graphic designers — the expert users. They reasoned that they didn’t want anyone to unbalance the layout by entering inappropriate combinations of text and images.

But these layout rules had been forgotten over time, hence the confusion years later. Consequently the tech team was often called up regarding a supposed bug (“I’ve put this image in but it doesn’t appear”), and effort was expended only to discover that it was in fact a feature — much to the caller’s amazement. Our micro-lesson there was to give the end users the freedom they naturally expected, including the freedom to decide for themselves what was a balanced layout. If what they produced was unbalanced then the designers would steer them back in the right direction — a much more human corrective.

Those clever layout rules were an anti-feature. They were additional functionality that actually made users’ lives worse. Eventually we removed them.

Anti-features happen in highly experienced mega-corporations, too. In November 2006 Joel O’Software started what became known as “the Windows shutdown crapfest”. He compared the three shutdown options of Apple’s OS X with the astonishing nine or more shutdown options of Microsoft’s Windows Vista. Not only is that confusing for the user, but it was also incredibly painful to develop — Moishe Letvinn, a former Microsoft engineer, tells the sorry story.

But at least the Vista shutdown anti-feature made the problem visible. In the layout logic example, and others I know of, there is silent intelligence at work that leads to confusion and frustration without giving the user any visibility at all of what’s going on.

Anti-features are time-consuming to build in, because any features are time-consuming to build in. But anti-features also consume additional time in their removal.

One way to prevent anti-features is to help the end user determine the long-term consequences of what they want. Of course, you’d hope they’d think of that themselves, but you can’t avoid your responsibilities to the project as a whole if you see something that others have missed.

Another way is to adhere even more fervently to the Agile mantras of delivering early (before every last sub-feature is there), keeping it simple, and focusing ruthlessly on only the highest value work. This way we deliver first a front page without clever corrective layout logic, or one or two shutdown options only, and consider further enhancements later if we find we need them. Suggesting and doing this is easier said than done, of course, but if everyone trusts each other to listen honestly to what they have to say then it’s more likely the decisions made will be the best ones.

Meanwhile we can at least ask ourselves each time: Is this a feature or an anti-feature?

There’s nothing so permanent as temporary

Temporary workaroundAn aphorism I heard recently seems to be particularly memorable: “there’s nothing so permanent as temporary”. However, it wasn’t originally referring to software — it comes from a builder who is rebuilding the kitchen of friends. He’s from Azerbaijan, and my friends are fond of quoting him in full, to give the words maximum colour: “As we say in Azerbaijan, there’s nothing so permanent as temporary”.

It is, however, as relevant to software as it is to building (and probably to many other areas of life). The constant pressure to deliver means there is very rarely the opportunity to go back and improve a nasty historical workaround which is causing problems today. However, there are some strategies we might consider…

1. Automated testing

If the nasty programmatic stickytape is relatively small then a comprehensive suite of automatic tests should enable you to make the change relatively safely and painlessly. Of course, you need to have built up that suite of tests in the first place. And the “relatively small” caveat is important, because only then can the software people fit the replacement activty into their daily work without disrupting any schedules. If there’s no external change then this is an example of refactoring.

If the nasty workaround isn’t so small, but really does need replacing, then a much more concerted effort is needed. A plan needs to be carefully devised which allows slow piecemeal replacement. The point of the plan should be to take baby steps towards the end goal; each step should also leave the system in a stable state, because you never know when you might have to delay implementing any subsequent step. However, if everyone in the team knows the plan then the end goal can be achieved with minimum disruption to the business’s schedules.

2. Act like a trusted professional

I find trust and transparency is an increasing part of the software projects I’m involved with. Part of this is that the technical people want to give their customers options, and are keen to explain the pros and cons, so an informed decision can be made.

However, while this is usually excellent, there can be times when it is too much or undesirable. Stakeholders don’t necessarily want to be given options for every single thing, and sometimes it’s right for a technologist to make an executive decision without referring back — because they’re a professional, and because they are trusted (and employed) to be professional. In this regard it’s sometimes the responsibility of a technologist not even to entertain the possibility of a temporary workaround knowing it will become permanent.

The decisions I’ve been close to in this regard tend to be architecture or technology decisions. For example, in my current work we have, roughly speaking, legacy technologies and modern technologies. Sometimes a feature requirement would arise which is quicker to implement in the legacy technology — but of course we knew it would be more costly in the long run. If the difference in timescales was not wildly divergent then I’d encourage my team to choose the modern technology and not to offer up a choice. These days I need to do that much less, because by building up that base of modern technology it’s now easier to expand and extend that for future features. By making hard decisions in our professional capacity earlier on we’ve made it easier to make the right decisions in the future.

3. Bite the bullet

A third way to remove the temporary workaround is to just be honest about the work involved and the cost to the business. Easier said than done, but an open and frank discussion followed by adjustment and agreement will ensure the issue is examined properly and supported more widely.

One example I remember is a particularly troublesome database table. Originally conceived as an optimisation with a few hundred rows, it grew over time to be a real albatross, slowing both development and production work, and running to over 19 million rows. However, we couldn’t replace it without a lot of effort, because its tentacles were everywhere; we needed to schedule real time for it, and that would mean less time for other, more visible, work.

But when we presented the plan, two things sugared the pill. First, we had long cited the table as the reason for previous work taking longer than anyone would like, so the cost of its presence was already felt tangibly. Second, we ensured our plan was broken down using the “baby steps” approach outlined above — it would take a long time, but it would take out no more than 10% of our resources at any moment, and we could always suspend work for a period if absolutely necessary. The plan won support, was executed, and after several months our DBA typed the SQL “drop” command and we popped a bottle of champagne.

Meanwhile, back in the kitchen…

Of course, all that is assuming the temporary workaround really does need to be replaced. In my friends’ kitchen they are actually quite happy with the drawer dividers they’ve requisitioned as a spicerack. Aside from anything else, it provokes conversation and allows them to talk about their Azerbaijani builder’s many philosophies. He seems to have so many pithy sayings — all of which begin “As we say in Azerbaijan…” — that they’re beginning to suspect he may be making them up as he goes along. Still, if he does have to make a hasty exit from the building trade there may be an opening for him in the software industry.

Project versus product

There’s more to software development than getting a software project delivered to the users’ satisfaction, on time and on budget. (As if that wasn’t enough.) Sometimes someone has to ensure the system lasts for the long term. But when that happens it’s a balancing act: between the project and the product.

The project and the product might start at the same point, but they usually finish at very different points. A project finishes with the last milestone release of the code — and a party. The product finishes with the opposite: the last byte of code being removed from the servers — and a party only if it was really nasty software.

The balance between project and product is something that I see again and again in many different forms. Here are some examples from different stages of the project lifecycle…

Project versus productTools: Java verus Ruby

There’s an amusing little spat going on over at Michael Coté’s blog. It’s a fairly traditional tussle of Java versus Ruby (and other scripting tools), in which Coté accuses Java people of being overly concerned with internal architecture, while Ruby (and LAMP and Django) people are more concerned with delivering the goods. But Robert Cooper adds the telling observation that the maintenance of the delivered goods could well be a nightmare if it comes from the scripters, because it often involves a “mish mosh” of technologies with non-standard dependencies.

Robert’s point, more generally, is that getting the application out the door is only part of what a software team needs to worry about, and the choice of tools has a bearing on life beyond the project end.

People: Internal and external

Having an internal software team is a wonderful thing. Among other things you can build up a huge amount of expertise, both technical and business-specific, which helps everything go much more smoothly. But sometimes bringing in consultants from out the outside has a benefit, too, and beyond mere extra bodies. Consultants get to see many different projects, technologies, businesses and people over a very short time, and they bring this accumulated expertise with them.

Mixing internal and external people like this can work really well. In terms of ideas, external people can bring ideas and propose directions that might otherwise not have been considered. Internal people are all too aware of the long term implications of these ideas in their organisation and can stop the crazier ones before they get too far. In terms of making the best use of time, external people are often particularly driven by project deadlines, perhaps because they’re often only employed for projects, so it’s all they ever know. Internal people can see the time spent now but also have a very good feel for time likely to be spent in the future, so can determine better when additional time within a project is actually investment for the future.

Sometimes work is outsourced entirely to external teams. Sometimes work is undertaken entirely by internal people. When the two kinds of people mix there is creative conflict, and the balance between project and product is tested.

Release: Releases rarely happen once

I once worked on a six month project with a big bang release. At the end of the project was a single release which took three days. That wasn’t three days of integration, testing and launch. That was three days from the point when the software was entirely ready for the end users, to the point where it was actually available to those users.

In terms of the project this was fine: on the scale of a six month project, a three day release is negligible. But when we came to release 1.0.1 and release 1.0.2 it was a bit excessive, and by release 1.0.16 it was actually a serious business issue.

There are many lessons to be learnt from this, but one is that we had erred towards the project too much and our lack of consideration for the product caused us problems very, very quickly.

Soup to nuts

It’s too easy to forget about the product in the rush to the end of the project. At one time I realised I was so negligent in this area I stuck a large message on my monitor in 36 point font:

…and how will that be maintained?

Balancing project versus product affects everything from who you involve at the start through to how you hit your deadlines and on to how it affects the rest of your working life (and possibly your non-working life if you find yourself on call). There isn’t a one-size-fits-all answer, but at least if we are aware of the tension between the project and product we have a better chance of making more informed decisions.

Series: One nice thing about three new sites

Today we’ve launched three new sites on Guardian Unlimited. Well, more correctly, we’ve redesigned and rebuilt our Science, Technology and Environment sites. Working for a media organisation, I can rely on people much more articulate than me to tell the stories better — see Alok Jha on Science, Alison Benjamin on Environment and (with more technical info than you can shake a memory stick at) Bobbie Johnson on Technology.

So I won’t repeat what they’ve said. Instead, I want to point to one tiny new feature which I’m unfeasibly excited about. It’s series. You know series. They’re those things which appear regularly in a paper or on a website.

Flagging that it's a seriesNavigating through a seriesIn our redesigned sites we’ve introduced series as a specific and distinct concept. For example, Bad Science is a weekly series by Ben Goldacre on pseudo-science. Ask Jack is a series in which Jack Schofield helps people with their computer problems. In the old world these articles would be gathered into their own sections and left at that. But a series is a little bit more than this. For one thing when you land on an article in a series it’s nice to know that it is one of a family. We now flag that at the side of the piece. For another thing, you should be able to navigate to the next and previous articles in the series. Again, this series-specific navigation appears with each piece.

It’s a very small thing, but to me it shows something fundamental and important: the software we’re producing really does match the way our writers and editors think. It is, for those in the know, a result of domain driven design. For everyone else, it’s simply software that does what you think it should do.

The truth about quick and dirty

“Quick and dirty” is a weapon that’s often deployed by people for getting themselves out of a tight spot. But like any weapon, in the wrong hands it can backfire badly. Technical people use techie quick and dirty solutions in their work. Those people we like to work so closely with — our clients — use their own quick and dirty solutions in their work. But what happens when these people come together? What happens when it’s not the developers or sysadmins who suggest their own quick and dirty solution, but when it’s suggested by our customers on our behalf?

When it’s the client who suggests we deploy a quick and dirty solution, there’s a few things that we need to consider…

1. What does “dirty” mean?

There’s no doubting what “quick” means. But what does “dirty” mean? It’s something that makes the technicians itchy, so it’s worth understanding why.

A dirty solution might suggest one that’s inelegant, that doesn’t conform to a techie’s idea of a good design. That might be true, but it’s probably not the core of the matter. Any decent techie who works in the real world doesn’t advocate elegant design for its own sake. They know that most of their designs are far from perfect, and in fact they probably pride themselves in maintaining a pragmatic balance between the ideal and the expedient — this, then, won’t necessarily make a techie uncomfortable.

So “dirty” doesn’t mean “inelegant”. I think in this context it means something which incurs technical debt. That is, it’s a technical shortcut for which we are going to pay a rising cost as time goes on. That’s what causes the discomfort — the knowledge that implementing this will be making the techie’s life, and the life of their client, difficult in ways that cannot be really understood until it’s too late. It might happen also to be a inelegant solution, but that’s by-the-by. The important thing is that “dirty” implies something which carries a cost.

Of course, the cost of dirty has the benefit of quick. And as we go on, seeing this in cost/benefit terms is actually very informative…

2. Who gets what?

If you’re my customer and I’m your techie, then there’s a significant and unfortunate thing about quick and dirty that I need to tell you: You get the quick, but I get stuck with the dirty. Or to put it another way: the cost and the benefit are not felt by the same person.

There are times and circumstances when this is not the case. If an individual sysadmin is making a judgement call about their own work, say, then they may choose a quick and dirty solution. And if we are considering an in-house software team with in-house customers, then the company as a whole will both benefit from the quick and pay the cost of the dirty.

But these examples don’t tell the whole tale. If our individual sysadmin is actually one member of a systems team, and has responsibilities to the team, then it’s their colleagues who are going to be sharing the cost — and in fact it’s not entirely correct to have called them an “individual sysadmin” in the first place. And while it’s true to say our example company reaps the benefit and pays the cost, it’s probably not the case that “the company” has made an informed and conscious decision about the cost and benefit. That’s because it’s very unlikely that such a decision will have been escalated to the single body responsible for both the cost and the benefit — the board, or the owner, or the managing director.

In the end, we must recognise that the one who reaps the benefit is probably not the one who’ll be paying the cost.

3. Who decides what?

The “who gets what?” question leads in to a more general point: experts must be trusted to make judgements in their own areas.

So just as a techie should not tell a customer how to do their job, so the customer should not tell the techie how to do theirs. And in particular, it’s not up to the customer to decide whether the technical solution should be a dirty one.

Of course, we should always feel free to make suggestions; no-one is so big that they shouldn’t be open to ideas. It’s fair and reasonable for the customer to ask the techie if they can do it quicker… and for that the techie would need to demonstrate some creative thinking. The customer may ask if there are better solutions… and the techie would need to do some research. And the customer might even suggest a specific technical solution they’d heard of… and the techie would have a responsibility to give an honest and informed opinion. But if someone is supposed to be the expert on technical issues then they do need to be free to make judgement calls on technical issues, including which solutions are and are not appropriate. That shouldn’t be a worry to the customer; as mentioned above, good technical people tend to take pride in their pragmatism.

And in fact, this should be good for everyone. By trusting everyone use their expertise we should get the best solutions.

Quick and dirty: cost and benefit4. How long does it last?

One final point on the cost/benefit view of quick and dirty: Quick lasts only a short time, but dirty lasts forever.

More precisely, the benefit of quick lasts from the time the quick thing is released to the time the “proper” thing would have been released; and the cost of dirty also lasts from the time the quick thing is released, but it goes on until the time the software is rewritten or deleted.

I’d say that unless software is a total failure it tends to last a very long time, and usually much longer than anyone ever would have wished. This is why the term “legacy software” is heard so often — if software was generally replaced or removed in good time then we’d never have needed to invent that phrase. And the fact that the dirty bits outstay their welcome means that the technical debt they incur is paid, and paid, and paid again… certainly long after the shine of being early to market has worn off.

But it’s not all bad

I don’t want to give the impression that quick and dirty is inherently bad. It’s not. Nor is everything quick necessarily dirty. Far from it; some things are just plain quick.

But if we’re talking about quick and dirty then it helps to think in cost/benefit terms. We need to be very clear about who’s paying the cost and who’s reaping the benefit, and exactly what that cost and its benefit is. If we can understand that, and if we can respect each other’s expertise in making these decisions, then we can be more certain that we’re making the best decisions a better proportion of the time for the long term benefit of everyone.

Guardian Unlimited’s new look: Some background on templating

We’ve just launched the single most visible, most complex, and most trafficked page in the entire network of Guardian Unlimited sites — the Guardian Unlimited front. And in so doing we’ve revealed more of a new design that’s due to roll out over the next few months.

There are some really lovely editorial and commercial features in there, but I can’t give the whole game away now. Those tricks and subtleties will reveal themselves over the next few days, weeks and months as the news agenda and business opportunities unfold. However, I would strongly recommending looking at Emily Bell’s piece which explains what we’re doing, and Mark Porter’s background on the design.

Since this is a technology blog I want to focus on just a couple of technical areas that I’ve been tracking — templating and layout, and some of the issues we’ve had there.

Velocity hello world snapshotKeeping it simple with Velocity

Like the GU Travel site, perhaps our highest profile release in recent months, the templating was achieved with Velocity. This is no secret; Velocity was named as one of our technologies when we were recruiting for client-side developers earlier this year.I’ve noted with raised eyebrows the Velocity versus Freemarker skrimishes that have blown up on the Net from time to time — they have been both lengthy and deeply felt. I can’t honestly say that we ran a detailed and open comparison when we chose a templating framework, but we consciously chose Velocity because it enforces simplicity. I once recommended someone to the Velocity documentation page, and one of our developers piped up “That’s what I like about Velocity, it has a documentation page“. Admittedly, it’s a very long page, but it’s still one page. That’s a sign of its simplicity.

But maintaining simplicity is difficult, and it’s too easy when faced with basic tools and a complex problem to create hacks and workarounds. One of our warning signs of things going skew-whiff was when our Velocity templates were becoming difficult to understand. I know a few people who would regard such things as the norm, that workarounds are par for the course for a jobbing techie. But complexity of the solution should be proportional to the complexity of the problem, and rendering data in templates shouldn’t be complex unless the data is complex. Also, one of the reasons behind the strategic decision to keep the development in-house was to ensure quality remains high throughout the software stack — we can resolve problems at source, not just where we have access.

In the case of complicated Velocity templates I was at pains to emphasise to our client-side team that they should expect simple, intuitive, relevant information from the back-end systems, and they should use this to ensure their templates are easy to read — if they weren’t getting this then they should tell the back-end developers. Conversely the back-end developers considered it their duty to provide simple, intuitive, relevant information to the client-side team, but needed to be guided as to exactly what this meant.

Consequently, subtle changes in the way information was presented, or accessed, made big differences. The back-end team ensured not only that the domain model was adjusted and expanded to ensure simple templates, they also built a number of tools to ensure the work of templating itself was more manageable.

In the end the Velocity behind the Guardian Unlimited front does remains complex. But it’s complex only as far as the visual design itself is complex. That feels appropriate to me.

Anatomy of CSS rule, thanks to josephtateCSS: Cascading scalability snafus

Because there’s an awful lot of content on the GU front there’s an awful lot of styling. And that’s brought with it its own problems. An Agile process encourages change, and as the work came together the design and the styling necessarily evolved. However, while change can be handled easily in software (thank you, JUnit and Eclipse) that’s not really the case with CSS — there’s no reliable refactoring tool that I know of.

I’ve previously found Factor CSS which reduced a 300 line file I gave it to 40 lines. But as one of our client-side team stressed to me, “Refactoring CSS is about making it more manageable, not shorter”. IntelliJ IDEA does better. It allows renaming of IDs, class names, etc, which is a huge jump forward, but far from the current state of refactoring in object-oriented programming. So refactoring CSS is important to us because of that manageability: this is software we’re writing for the long term.

CSS editing with IntelliJ IDEAThus a short time ago we embarked on a manual refactoring exercise which rounded up all those tiny changes that had crept in throughout the Agile design process. When we began we had a single global CSS file of several thousand lines. That horrified me, though I suspect it wouldn’t be shocking to those who work on this kind of thing full time. There is debate within the team as to whether this is to be expected — “CSS doesn’t scale,” / “Yes it does, but we’re still on the learning curve”.

Either way, we’ve now split it out across several more manageable files and removed a lot of duplication and redundancy. No-one thinks we’ve achieved an ideal, but we think we’ve done what’s pragmatic for now. The team has achieved this partly through dogged hard work, and partly with a bit of innovation. The hard work needs little explanation — it’s work, and it’s hard, and it’s part of any job, although in this case it does have the virtue of rewarding you with incremental results at every step of the way. The innovation is in the way we link CSS templates to the on-page components that they refer to, so that each component pulls in its own CSS if necessary, and only if necessary. This ensures we can isolate component-specific CSS quickly and effectively, and therefore be more confident in our refactoring.

However, I’m left with the feeling that web design is a good way behind back-end software development when it comes to management.

Domain Driven Design book coverSeparating presentation and content

Of course, separation of presentation and content is second nature today, if rare in older systems. I noted with interest that when Yahoo! News UK relaunched recently one of the innovations listed was “proper separation of presentation and content for the first time”. Yahoo! News UK and GU clearly have more in common than just what’s on the surface.

But while the fact of presention and content separation is well-established, the two sides must communicate and how this is done is much less certain. To give a particular example, when we display an article the content consists of obvious things such as article body, headline, byline, etc. Our early adherence to domain driven design (DDD) led us to ensure that this content — and only this content — was visible to the Velocity templates. This sounds fine in theory, but in practice wasn’t good enough: the visual design of the page also depended on knowing non-domain information such as where the 200-word point was, or the dimensions of the associated image.

These things are part of the presentation logic, so need to be kept separate from the domain logic. On the other hand, they also need to be kept separate from Velocity, because that’s a templating framework, not a programming framework.

For these reasons passing in “fake” articles with extra (non-domain) information violated the architectural principles of DDD and lost us its advantages. We also flirted briefly with creating and exposing objects such a DecoratedArticle (using the decorator pattern) but this didn’t pass the intuition test. A DecoratedArticle is not an intuitive thing to anyone except an experienced software developer.

It took some time to evolve a solution that ticked the boxes for domain driven design, simplicity, intuitiveness and manageability. It involved small alterations in our templating patterns, among other things.

The GU front in retrospect

The work to date on the GU front has been far from trivial — not only because of the issues above, but also because of things I’ve not talked about such as performance and the software our editors need to keep updating it.

Along the way we’ve tackled new and difficult technical issues. You might think it’s odd that such issues weren’t resolved last year when we were working on the Travel site which is really part of the same system. But, as I said before, the GU front is probably the single most complex thing we could release. It’s only when you force yourself to confront the most difficult issues that you are forced to see root causes and address them at source. This is particularly so as there is much more work to come. As Emily says, “our view is that for a more technically robust site, which will be a platform for far more rapid developments in the future, an iterative approach is the best”. So we’ve made a good decision to face the difficult stuff sooner rather than later. There will be more technical challenges to tackle in the months ahead. But for now I can say we’ve resolved some really core issues in ways that should hold us in good stead for a long time to come.

Want a job in video or audio?

My colleague Neil McIntosh writes on his blog:

I’m pleased to report this blog has had some success on the recruitment front, so here goes again… and this time, it’s for two of my teams.

Indeed, one of the new members of our expanding software team found their way to us through one of Neil’s previous (and snappy) posts. As he remarked at the time, “Possibly the most profitable eleven words I’ve ever written.” (If so, only because your other writing is invaluable, Neil, only because of that…)

By way of returning the favour, I’m happy to say our multimedia capability is also expanding significantly, and we have eight new positions covering four distinct roles: Head of Audio, Head of Video, Audio Producers and Video Producers.

Take a look at Neil’s blog for some background. It’s probably one of the most exciting A/V opportunities around at the moment, and certainly a terrific bunch of people to be working with.

What management buy-in really means

We work using agile development processes, which obviously needs the buy-in of internal users and project sponsors. But this jumped out at me when I read it. It’s from Carolyn McCall, Chief Executive of Guardian Media Group, which owns the company I work for. She was announcing a £15m investment in our digital business, and it was reported thus:

“What we’ve done so far is our own version of web 1.0, but we want to continue to web 2.0 and what comes after that,” Ms McCall added. “We need to be agile and ready to change.”

I suspect that phrase, “We need to be agile and ready to change”, is not a coincidence. You can trace a strong lineage between the agile development work going on in Guardian Unlimited and that little sentence in a speech to the OPA. Let me tell you how I think it got there.

A story of a sentence

A long time ago we began using agile processes in the GU tech team. It was a new way of working, but it seemed to address a lot of our problems — actually, the usual ones you get in most software organisations, such as knowledge silos, lack of flexibility, impossible deadlines, and so on. Changing what you know is always a tough choice, but the GU management team were very supportive of the move to agile.

In particular, our boss at GU at the time, Simon Waldman, was very interested in its implementation and evolution. (Simon’s since moved to GMG.) Over the months and years he enquired, queried, provoked, but was never less than encouraging and constructive. (At one memorable annual review to the GU staff Simon devoted an entire slide to explain how we had stealthily removed a problematic database table. Our DBA was thrilled; I have no idea what the attendant sales people and journalists made of it.)

And agile clearly worked for GU. One notable change was that planning meetings took on much more of a business focus. Far less about technical dependencies, much more on what functionality we wanted to release when.

And then we began we work on our new Travel site (released in November). It featured a new design and new commercial opportunties. More people around the company needed to scrutinise this as it started up, because it was a pretty big project and we had a much greater responsibility to be rigorous and transparent in our delivery. We saw agile methods as being critical to the work’s success. It would allow us to delay decisions to the latest possible moment and therefore produce something that was much more relevant — both editorially and commercially — to our audience and clients.

I therefore spent some time explaining agile to various company directors… but not as much as you might expect, because clearly the principles and practices had been discussed and understood well before. I ended up having the kind of conversations about agile development with non-technical senior managers that I wish I could have had with more technical job candidates. Word was getting around. The business people scrutinising the work on the Travel site understood the process’s business benefits, and they understood how the low-level practices would provide those, and they knew those practices were working successfully within GU at the time. And indeed, the project was blessed by the the company directors, including Simon and our MD at the time… Carolyn McCall.

You can see how that word “agile” has been thrown around a lot inside the company, and was — at least then — strongly associated with Guardian Unlimited and therefore its innovation (which I’d like to think is almost synonymous with “daily work” — ahem), and it’s stuck.

Now I can’t claim that Carolyn knows what, say, test-driven development really is. I suspect she has higher level things to think about. But if it came up, I think she’d understand our practices such as refactoring (making lots of tiny internal restructurings to produce a smoother, more manageable system), continuous integration (ensuring our changes are constantly integrated into the day-to-day work, not siloed) and retrospectives (frequent reviews and actions to improve). And, come to think of it, TDD, which is really about supporting and enabling change.

It seems Carolyn understands “agile” in a way that I wish more technical people would. It’s about change, and about supporting change (“We need to be agile and ready to change”).

The hard work starts now

And what of the future? Well, agile development helps us deliver responsibly to the business — and if someone invests £15m in you, then you really need to deliver responsibily. Again, that kind of investment only happens if there’s confidence in your ability to deliver. Can we offer that confidence? Well, just this week I was in a meeting with Tom Turcan, who is our Head of Digital Media Development. The conversation went something like this. Note that development for this particular thing is already about 30% of the way through:

Expert user: “…So in summary we’ve decided that features A, B and C aren’t that important after all, and we’ve replaced them with features J and K.”

Tom: “It looks like A, B, C total 7 ideal days, and J and K total 8.5 ideal days. So that’s a net increase of 1.5 ideal days. Is that right?”

Expert user: “Er, yes.”

Tom: “So we can’t really allow that to happen. We can make changes to make the work less, or keep it at the same level, but we mustn’t start increasing it. Can you find 1.5 days’ worth of features to remove?”

Expert user: “Yes, I should think so.”

Tom: “Okay, we’ll make a note to see what you’ve decided next week.”

We couldn’t have had that conversation in a more waterfall environment. By the time we’d have reached this point the groundwork for A, B and C — the database tables, the DAO layer, etc — would have been done, and it would have been wasted effort. Instead our expert user is able to make decisions later, and Tom is able keep to keep the work under control, giving the rest of the business the confidence it needs. Our agile processes enable that to happen. And all that is known by our developers, and by our managers, and that same confidence is shared by our group Chief Executive.

Postscript

By the way, there are other things going on this week in and around Guardian Unlimited. You might want to take a look at Jeff Jarvis’s commentary on Alan Rusbridger‘s commitment to digital and his interest in being flexible. Also, my esteemed colleague Neil McIntosh tells how GU saved a cat, and offers a word of advice to a researcher at News International.

As a friend said to me the other day, “I know when you’re busy at work — your blog goes quiet.” So back to work now.