Putting a Finger on Rework

October 8, 2006 by
Filed under: People, Process 

I gave a couple of presentations at a conference this week. In both talks, I dropped the oft-quoted industry statistic (appropriately prefixed with the dreaded “Studies show…”) that in software teams, 30-40% of all their time is spent in rework. Reference to the same stat was used by at least 2 other speakers at the conference as well.

There was little overlap in attendance between my two talks, so my blatant reuse wasn’t a big issue. Whether or not that lack of overlap is an indication of the quality of my first talk is a separate mystery.

Another mystery is that after all this time, most people in software are still surprised that they spend at least that much time in rework.

During one presentation, there was some healthy debate about exactly how to define rework, with some of the usual concerns. Do we count the time we spend fixing our stuff before we pass it out to others for consumption? What about the time spent in refactoring (never mind the debate about whether we are actually performing healthy refactoring or just politely describing post-implementation design)? How about all that stuff that comes back in maintenance after deploying the system, that’s never charged back to the original development project in the first place?

Someone approached me after the talk to chat about rework. Based on the presentation, he was aware that I had written a few articles for magazines, and he asked me how much time I had spent in rework on those articles. I was about to answer, but I had to stop myself, as I had 2 very different answers battling for dominance. I was now looking at the question of rework from a different perspective.

My response was to pull out the old favorite of consultants everywhere. “It depends”.

Let me explain.

The first time I submitted an article for a rigorous review, the feedback I got absolutely floored me. All sorts of comments about how to restructure the paper, questioning some of my key assertions, suggestions that some areas were irrelevant to the topic I was writing about, and some things that just didn’t appear to make any sense to the reviewer.

Time to crack open a six-pack. I was devastated.

It took me the better part of two weeks to get back to reviewing the comments again, and only then because the next deadline was looming. This time around, though, all these comments that were originally demoralizing now actually seemed constructive. They helped make the article flow better, focus more clearly on the topic and more precisely defended my assertions. The review process in writing became a very powerful, sought-after approach to writing, and I have come to appreciate that I learn a great deal and produce a better product because of it.

The same thing had occurred in the software space much earlier (including the six-pack), when I was first exposed to the results of rigorous and effective peer review of my software work products. A thorough review from an external observer cannot help but generate a great deal of potential for refinements to a work product, and this is something that we need to learn to value in a team environment.

Even though I found that both of these first exposures were great learning experiences, they both resulted in what I would call massive rework. The effort working on both of these products more than doubled what I had invested for these first drafts, and – this is the key point – the extra effort caught me off guard and was not adequately scheduled for. Some other things would have to give in order for me to deal with the feedback.

These days, when I put together the first draft for a magazine article or conference and submit it for review, my attitudes about what happens next have changed dramatically. When I’m publishing an article, I don’t have expectations of being done until my reviewers and I are all happy with the results, and this is a long way from the point where I have submitted my first draft. Indeed, the first draft may only be 20-30% of the overall effort expended. All this effort is not rework, this is converging on a solution. It is the same overall effort as the first experiences (minus the angst, perhaps), but a healthier and more reasonable perspective. Given that past experience, I can even estimate and plan for that effort.

Given these experiences, I would define rework as follows. Any time you hand off a work product to be consumed elsewhere and experience a sense of disappointment when that work product comes back to haunt you, that’s the stuff we want to minimize. If you have passed along your work for peer review or test or further implementation and don’t expect, or wish for, or allocate time for dealing with the feedback that may come your way, you are setting your self up for rework. Any time you touch that product again in the future, you time is being spent in the rework category. By this definition, there is no ‘good rework’.

In software, we’re often caught building something on our own and effectively shipping this work product for others to consume, either internally or externally. We’re then disappointed when it comes back to haunt us with problems others have found, and we have to steal cycles from our otherwise planned work to fix the problem. Wrong.

Converging on a shared understanding of what constitutes rework needs to take into consideration what our expectations were in the first place. I’d say that if you find yourself surprised and disappointed that you are back working on something that you hadn’t anticipated revisiting, you are in the midst of rework. Regardless of whether you naively underestimated the content and value of review and constructive feedback. It is this rework that you want to minimize, either by cleaning up your expectations of the effort it reasonably takes to get the job done and scheduling accordingly, or by actually doing this effort so that problems don’t come back to bite you later. Or both.

We want to be able to plan our work and work our plan. Much of the work that hasn’t been planned in advance is rework. With different expectations and schedules, two people producing the same work product in the same manner can have very different rework experiences, even if there is no difference in overall effort. Avoiding surprises may not mean a reduction of effort in all cases, but it sure makes it easier to retain job satisfaction. – JB

If you enjoyed this post, make sure you subscribe to my RSS feed!


Feel free to leave a comment...

  • What’s Happening

  • On The Road Again

    Jim frequently travels across Western Canada for engagements, and welcomes opportunities to meet, run a workshop, Diagnostic or Lunch and Learn session.

    Contact Jim if you would like to connect around any of the upcoming dates:

    • Blissfully at home in Vancouver, BC over the summer!
  • What People are Saying

    If your desire is to effect change or have more influence on a software team, you could either stumble around in the dark for a few years, experimenting with different techniques, or you could buy, read, and apply the techniques in this book. This choice, of course, is up to you.

    — Matt Heusser