niksilver.com

While I’m usually proud of the work I’m involved with, I’m rarely happy for long. There are always ways to improve, and I’m usually dissatisfied by one unmet ideal or another. Almost since I started in this field I’ve been vexed by how much of web development is “urgent” rather than “important”. This is not merely of theoretical interest; it vexes me because dealing with important issues gets you to something of lasting and strategic value, while dealing with urgent issues gets you to the next day. It’s that unmet ideal of achieving more long-lasting value that causes me to think about this.

I want to give some context around the claim that there’s more urgency in web development, and then I want to offer some ideas about why this might be. If you want the brief version, I think what makes the web generate such urgency is that…

1. Updates are cheaper;
2. Problems hurt less;
3. Competition is more visible;
4. Boundaries are blurred; and
5. It’s easier to have more stakeholders.

But first, some context.

Some context

Although I do think web development has a surfeit of urgency, it’s fair to say that “web development” is not a clearly defined area. So much software today has some link or other to the web, it’s usually unfair to say definitively that something is or is not web development. So it’s a matter of degrees, and looking back on the software development I’ve been involved with I’d say the more web-oriented something has been the more I’ve had to deal with urgent issues, and the less web-oriented something has been the more I’ve had to deal with important issues. The most urgency comes when working on websites, and the least when working on applications which may or may not use the web for a bit of minor communication.

This issue of urgency also seems to be the perception and expectation of non-technical people. This is how we get the phrase “Internet time” and why for years I’ve heard people saying “but this is the Internet” as a justification for tight deadlines. This is something that continues today, even after the unsustainable boom and bust of the dot.com years.

When urgency is too pressing we risk doing a bad job, and releasing something which isn’t up to scratch. Of course, when urgency isn’t pressing enough we lose ground to our competitors. And of those two scenarios it’s the first one, doing a bad job, which is easiest to spot: a bug bites someone on the nose and you get to hear about it pretty fast. The second scenario, losing to the competiton, happens slowly over months or years, and by the time you slip into obscurity so many events have occurred it’s hard to pinpoint exactly where you went wrong.

Urgency is no bad thing, then, but I continue to be bothered by its dominance in web development. Too much urgency leads to a loss of quality and a reduction of strategic actions. Why does this happen in web development more than elsewhere? Here are some thoughts…

1. Updates are cheaper on the web

Rolling out a new version of a website onto a server shouldn’t be regarded as a trivial affair, but it’s a lot easier than other means of releasing software. So it’s easier to release a slightly rushed product if we know the only copies anywhere in the world live on servers which are entirely under our control.

Slightly more costly than updating our own servers is the job of the IT department which has to update an application on everyone’s desktop. Here, not only do you have to be sure the desktop machines are all switched on and ready to receive the software, but an error for one person could mean they cannot work at all the next day. More costly than that is the job of burning, boxing, and shipping a DVD to hundreds of retail stores.

For both those cases, and for many other ways of releasing software, the cost of repetition and the cost shipping something substandard is very high. But in many web applications, where the cost of distribution and the cost of error is relatively low, the consequences of problems that come from an urgent release are much less costly.

2. Problems hurt less on the web

As users, our relationship with websites and web applications tends to be less engaged than with most other applications. So although we all know undue urgency leads to more faults being released, it’s perhaps more forgivable on the web.

If I’m using a website and I encounter an error, I know the problem — the website — is theirs. I can come back later or try an alternative (there are always plenty of alternatives on the web). Either way, I’m probably not going to get very upset.

By contrast, if I encounter a problem with software running on my machine then any error is going to hurt me much more: that’s a problem with my software… it’s causing my machine to go wrong… I went to the trouble of installing that software and now it’s giving me problems… this is not good. Even if the software was installed by my IT department it’s still my software, and it’s core part of my daily work — finding a workaround is going to be difficult.

3. Competition is more visible on the web

One of the drivers of urgency is beating the competition, and if you and your competitors all work on the web, then they are likely to make (cheap) incremental releases, and you will notice almost every one.

If competitor A releases a new feature in week 1 then you’ll notice and ask how you can do that yourselves. If competitor B releases another new feature in week 2 then you’ll notice it and ask how you can beat that, too. By the time competitor C releases a third thing in week 3 you’ve got the pressure of the three things being delivered by your competition and nothing to show yourself.

Things are different as you move offline. Consider software companies in a competitve marketplace that see software ship features in batches. When your competition ships their new release with new features you’ll be able to assess all those features as a whole. Of course there will still be intense pressure to deliver, but your view will be more rounded and decisions of importance will play a greater role than decisions of urgency.

Consider also the internal team which delivers software which is internally-facing. Your life in this team will be no less demanding than in any other, but one thing you’ll be spared is much pressure from competitive teams. If you’re delivering the next version of the payroll system then there will be pressure of deadlines, there will be pressure of budget, but you’re very unlikely to get an unexpected new requirement due to the payroll software team at your competitor suddenly releasing their new e-mail alert module.

None of this is to say that competition is more fierce on the web. That may or may not be the case, but it’s not what I’m interested in here. The point is that the competition seems more fierce and is much more visible. This encourages urgency.

4. Boundaries are blurred on the web

A wordprocessor helps you write documents, a media player plays audio and video, but a website… a website doesn’t have clear boundaries.

Although I wrote above of competition, exactly who is a competitor on the web is not always certain. I once worked with an e-commerce music retailer who suddenly decided they needed to provide a web mail service for their customers. I’ve worked with a law firm who wanted to turn their brochureware site into a recruitment platform. Yahoo! evolved from a directory into a portal, embracing almost everything they could while the world struggled to understand what a portal might not be. Meanwhile, stepping away from the web, I don’t know of a spreadsheet which carries a discussion forum or an HR system which recommends movies.

While all this clearly accounts for the quantity of demands that occur in web development, it also accounts for the urgency because that steady drip-drip-drip of features that comes from our competition also comes from those who aren’t direct competition but are just out there on the web. The drip-drip-drip becomes a trickle (and maybe even a flood) pretty quickly, and the pressure to deliver new things is even greater.

5. It’s easier to have more stakeholders on the web

Because the web means so many things to so many people — contributing to those blurred boundaries — many more people within an organisation will consider themselves stakeholders. Marketing people see it as a marketing tool, the recruitment team see it as a recruitment tool, the sales team see it as a sales tool, and so on. And of course each one of them is right: it can be all these things.

With so many diverse stakeholders, we can expect so many more pressing deadlines, and hence much more urgency. More stakeholders also means communication and prioritisation is more difficult. It’s difficult to get everyone into the same room, it’s difficult to bring everyone to the same point of understanding, it’s difficult to weigh completely different kinds of requirements against each other. It doesn’t matter that everyone is working for the same company and therefore, at a higher level, the same goal. That goal is usually at too high a level to make a difference to everyone’s day-to-day needs.

The least pleasant example of this I remember is a colleague at a previous company who was the project manager for one of our clients. Although he was their single point of contact they managed to have several single points of contact, none of whom were very good at speaking to the others. He found he had responsibilities to the marketing manager, the distribution manager and the IT director. They all had pressing demands, and he had no contact with anyone who could bring them all into line. Indeed, that seemed to be by design, as we suspected the client used this as a way of squeezing us as a supplier. The relationship did not end happily. Although that’s a very extreme example it does highlight the kind of difficulties of having many stakeholders.

A final word

Cheaper updates, less damaging problems, more visible competition, blurred boundaries and more stakeholders. This tends to be the world of web development, and therefore a world in which urgency plays a more dominant role.

Yet we can think of web development projects in which importance dominates urgency. One which springs to mind is an online banking site: this is web development if ever anything is, but one in which doing things quickly will always be trumped by doing things properly (whatever “properly” may mean for that bank). But this is also an environment where many of the criteria I’ve listed don’t hold. Most obviously updates will be fairly costly, any problems will be very damaging, and the boundary of what the site does is very well defined.

So the criteria I’ve set out above are more to explain than define. Web development tends to take place in an environment that’s different from many other software development environments, and I think it’s those features of that environment that I’ve listed that explain why urgency predominates.

I said at the beginning this vexes me because urgency causes visible problems, and eliminating urgency would seem to help eliminate those problems. But I also said I’m usually dissatisfied with one unmet ideal or another. I’ve also worked in environments where there is a distinct lack of urgency. That, of course, leads to waste and stagnation. And that’s really, really, vexing…

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.

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.

Mishkin Berteig says that rotating developers in and out of a support team should never be considered. I’d argue that he’s wrong, and that it’s often highly desirable and should always be considered.

In this article:

• Background. In which I outline what this is all about.
• Support rotation is desirable. In which I explain five reasons why rotating people through a support team is actually a good thing.
• Two asides. In which I get a little upset at the tone of some of some of Mishkin’s words (but only because I know he carries weight, you understand).
• When rotation is bad. In which I try to add a bit of balance.
• Summary. In which I round things off and try to make everybody happy.

So onwards…

Background

Mishkin Berteig writes about ways of handling software support — a much under-discussed issue in the public forums. But along the way he makes a comment I’d warn anyone to beware of:

A third common method is to form two separate teams: one doing new work, one doing support work. This is simple, effective, and annoying for the people on the team doing the support work! Please don’t consider a rotation system since this destroys the process of team development and makes it nearly impossible for the team doing new work to learn their capacity for the purposes of commitment.

I’d say the opposite: in many cases a rotation system is an excellent thing, is something to be strived for, and should be considered by anyone who needs to manage software support. Here’s why. I should say I’m going to blur the line between “support” and “maintenance” most of the time, here. I think that just reflects a lot of reality — support ranges from bug-fixing to minor improvements to not-so-minor improvements.

Support rotation is desirable

Let me count the ways…

1. Rotation win: Treating developers equally

Any manager wants all their developers to feel that they’re treated fairly. If support is considered different to project work (and it’s usually thought of as being less glamorous) then you won’t want a few of them consigned to the lesser work for all eternity. And they won’t want that either. Rotation into (and out of) the support team ensures everyone knows they have no greater or lesser privileges than anyone else when it comes to sharing the workload.

This issue becomes even more acute when we bring two other groups of people into the mix: contractors and new joiners. When new members or contractors join it’s so much easier to drop them into a nice, sandboxed project. They don’t need to know about all that long term legacy stuff that’s been around for ages and needs supporting. And so it becomes less likely that the longer-serving developers will ever escape the support team. Your longest serving developers — the very people who have stuck with you through thick and thin — will become those who feel most hard-done-by. Ensuring rotation through the support team evens all that out.

2. Rotation win: Maximising your team’s experience

Software development can’t be learned just by doing either project work or support work. You learn by doing both. The best developers talk not just about creating new code, but also about maintainability, and will do so from experience. Just from a general perspective people need a breadth of experience.

But that’s important, too, even at a more specific level. It’s no good writing a piece of software and they saying adios the moment it’s launched. An application arguably only begins its life when it’s released. That’s when it starts to be really used, when it meets its users, and that’s when the lessons are to be learned.

Oh, that class really doesn’t make sense after all… That design for the whizzbat component really isn’t doing us any favours… Thank goodness we designed the look-up tables as we did, we should remember to do that again.

I’ve said to individual developers before, and I’m sure I’ll say it again, the codebase has to be in a better state after you’ve touched it than before. That skill is really best developed in a support team. A developer who doesn’t experience the full lifecycle — either in general or of a particular piece of software — isn’t learning as much as they could. Rotation through the support team ensures a broader experience and better insight into their trade.

3. Rotation win: Knowledge sharing

Fascinating that Mishkin advises against rotation “since this destroys the process of team development”. I’m not sure if he’s referring to developers’ general experience or to learning about the particular software that’s coming together in the project. If he’s talking about the former then I’ve covered that above. But if he’s talking about the latter point, then team rotation is an excellent way to ensure it.

Of course rotation can happen within a team to ensure knowledge sharing. If you do pair programming, then pair rotation promotes knowledge sharing within the team. But more than that, rotation between teams shares knowledge even more widely. If you’re going to do frequent releases then that release suddenly goes into maintenance mode and needs to be supported. If you can rotate a project team member into the support team then the support team as a whole suddenly gains knowledge of the software, they can live up to their new responsibility, and individual team members can learn from the incoming developer.

4. Rotation win: Maximising internal prospects

There’s a corollary to rotating developers from the project team into the support team throughout the life of the project. And that’s that it prevents the situation where the project team completes the project and then stays with it for life because they’re the only ones who understand it. In that situation the team as whole changes from a project team to a support team, and worse than that, they have no variety and become the support team of just a single product. By constantly refreshing the project team you ensure that developers can see that their prospects within the organisation are maximised.

5. Rotation win: Facing up to difficult issues

The issues above are mainly benefits to developers. But there’s a benefit which is solely for the manager and the business as a whole: aiming for rotation through the support team forces the manager to face up to difficult issues, whether that’s maintainability, team motivation, or knowledge sharing. Support rotation is a concrete and visible goal. By aiming for that goal you’re aiming to confront those issues, and as long as you’ve not (visibly) achieved it you’ve not dealt with the issues. Rotation through the support team provides a visible mark of success.

A couple of asides

Two things in passing. First, I think of the knowledge sharing issue almost as an extension of extreme programming. The principle in XP is, roughly, take all the good things and turn the dial up to eleven. To me, knowledge sharing is a good thing, and rotation between teams is one way to turn that dial right up.

Second — and I’m really reluctant to raise this, but think it’s important — we’ve got to be very careful about being prescriptive. The throwaway phrase warning against rotation (”Please don’t consider a rotation system since this destroys the process of team development and makes it nearly impossible for the team doing new work to learn their capacity for the purposes of commitment”) has too many bad echoes for me of the “you call this agile?” ding-dong.

You may recall that also began with a remark posted on the Agile Advice blog. There, the author seemed to categorically refuse any interruptions to his developers’ week on the grounds that two hours’ interruption can waste the entire week. Joel O’Software countered this, suggesting that maybe, just maybe, an interruption might be okay. There were arguments both ways [1, 2, 3, etc]. In both cases — on rotation and interruptions — the impression is created that developers are revered saints who need near-religious attendance or they’ll fall to pieces. The best developers I know have their feet planted firmly on the ground, and the best businesses I know treat developers with respect not because they’re developers, but because everyone there treats everyone else with respect. It’s very rarely black-and-white when methodologies meet reality. We need to be pragmatic, not dogmatic, and we need to be seen as such.

Thank you for indulging me. Now back to our regular programming…

When rotation is bad

Yes, yes, one mustn’t be dogmatic. Rotation in and out of the support team won’t always work…

Caution: It’s disruptive

Rotation is disruptive, for exactly the reasons that Mishkin gives, so it’s got to be balanced against everything else that’s going on in the business. Rotating a developer every day is clearly going to be a bit much. But rotation can be planned to minimise disruption. The point when one iteration stops and the next starts is obviously a good opportunity. Maybe not between every iteration, but at appropriate project milestones, when people return from holiday, and so on.

Caution: It depends what “support” means

In all the above I’ve really thought of “support” as being almost synonymous with “development on a very small scale”. But it’s not always like that. In many cases software support involves telephone support, or perhaps meeting paying customers. Clearly this requires a very different (interpersonal) skillset than you’d look for otherwise in a software developer. Many developers don’t want to spend time meeting besuited customers, and in these cases you’ll end up hiring different kinds of people for different kinds of teams. Clearly here rotation isn’t going to work.

On the other hand I should say I know a few developers who do like meeting customers, and who do like solving problems on the phone. And I also know developers who like maintenance work without meeting customers because it gives them a strong sense of satisfaction to see a closed problem solved in a timespan that’s a fraction of most projects.

Caution: If you’ve already committed

There’s also one final occasion when support rotation is difficult, and that’s when you’ve promised people otherwise. Perhaps you’ve undertaken to a new recruit that “no, we won’t put you on support”. Or perhaps you’ve promised a particular client that certain individuals will stay on their project to the end. In these cases, obviously, you’ve got to honour your word.

Summary

Support is a very, very under-discussed topic, particularly in the field of Agile development where the writing tends to be about projects rather than maintenance. So Mishkin Berteig has done us all a great service by spending some time on it, and offering suggestions about how it might be managed. But there are probably more ways than even he suspects, and in particular — and against his advice — I would very strongly recommend giving serious consideration to rotating developers in and out of a support team.

It’s not easy to manage, and there reasons not to do it. But there are also plenty of very good reasons that it should be done, and hopefully the words above will encourage its wider adoption.