Author Archive

Defining developer productivity

Can you measure the productivity of an individual developer or team of developers? Do you really want to? If the answers to these questions are “yes”, the first thing you’re going to want is a clear definition of productivity.

(I was inspired to write this article by a thread in the scrumdevelopment Yahoo! group titled Executives Tracking Individual Developer Productivity?  The originator of the thread wrote about a real issue in his company that had to do with the CEO wanting to measure the productivity of the company’s developers based on the principle that  “you can’t manage what you can’t measure.”)

Productivity good!

We can probably agree that productivity (in the abstract) is a good thing, but can we agree about what it means concretely? For starters, what are the “units” of productivity for individual people or teams?

For example, we can compare the gas mileage of vehicles to each other in units of  “miles per gallon”, and we would probably agree that vehicles with higher numbers are more productive.

What units could we use to compare individuals or teams in a similar fashion? One commonly-employed notion from our past, and one that we have thankfully left behind, is that developer productivity could be measured in lines of code produced in a given period of time. But if that’s behind us, what are we left with?

Productivity defined

The business novel The Goal defines productivity as follows:

“Productivity is the act of bringing a company closer to its goal. Every action that brings a company closer to its goal is productive. Every action that does not bring a company closer to its goal is not productive.”

Sounds simple enough. Now all we have to do is to figure out what the company’s goal is, and we’re there.

Do you know what your company’s goal is? Not its mission statement, but its goal? Is your company in business for a profit, or do you work for a non-profit concern? Most of us, I believe, work for companies interested in making a profit. And if that is so, then most companies’ goals might very well be as simple as making a certain amount of profit per year.

But we’ll probably want to measure the productivity of our developers more frequently than once per annum, so we might express the productivity of an individual or team in terms of “profits earned per iteration”.

The thing is, can we actually measure the contribution to profits made by an individual developer or even a team of developers? Offhand I’d say that this is a difficult proposition, at best.

However, I contend that if we cannot correlate the productivity of an individual or team with profits, then there really isn’t much point in trying to assess that productivity in the first place.

Looking where the light is better

There’s on old joke about a man who is searching the area around a corner streetlight. A second man comes along and asks him what he’s doing, and the first man replies, “I’m looking for a quarter that I dropped.” The second man joins in the search, but neither man is able to spot the lost coin. Finally the second man thinks to ask, “are you sure you dropped it here?” The first man replies, “no, I dropped it in the alley, but the light’s better here.”

In a for-profit company, attempting to measure the productivity of a developer in any terms other than contribution to profits amounts to looking where the light is better. In other words, don’t measure something just because it’s convenient to measure.

Software engineering isn’t

There’s a long tradition (since 1968, according to Wikipedia) of looking at software development as an engineering discipline. But calling software development engineering is something like adhering to the letter of the law, rather than to the spirit

Software development is about acquiring knowledge

If you think of software development as strictly an engineering discipline, you might be inclined to believe that the job of a software engineer is to apply his or her previous knowledge and training toward solving a particular problem. And you’d be right, to a point, because knowledge and training are important aspects of software development.

But you’d also be missing the key factor, that software development is mostly about acquiring new knowledge. Software developers are always engaged in the following pursuits:

  • Discovering what to build
  • Discovering how to build it

This goes a long way toward explaining why so much software is custom software. If software development were entirely an engineering discipline, it is conceivable that we would be able to construct just about any software application by plugging together the proper parts, chosen from a catalog of well-known, existing components. The fact that we aren’t even close to being able to do that is an indication that we still have a lot of discovery ahead.

Discovering what to build

How do we discover what to build? By working closely (and continually, if possible) with the customer. By getting feedback as often as possible from real users, and by constantly applying that feedback to the product under development.

Discovering how to build it

From the developer’s perspective, this is a career-long pursuit, as new techniques for building software are always appearing. As software developers, we can provide the greatest benefit to our clients by being aware of new developments in the field, but tempering that with the client’s needs to meet specific schedules and cost targets.

For any particular product, we can practice Test Driven Development (TDD) and encourage emergent design, so that we avoid imposing our own pre-conceived (engineering) notions on the product, and instead develop just what the client needs (and no more).

Avoiding the knowledge transfer bottleneck

In software development there are many ways to transfer the knowledge about how to build a product to the people who do the actual building. Production can be severely hampered, however, if that knowledge is being produced more rapidly than it can be consumed. This is the knowledge transfer bottleneck.

I recently hosted a workshop that let participants experience three different ways of transferring knowlege in a production environment. The product, in this case, was a paper airplane of unusual design. The idea was to try different ways of transferring the knowledge about how to build the airplane from the “chief designer” (me) to the production workers, and to compare the relative productivity of the different methods, which were:

  • Documentation – The workers were given written instructions (22 steps worth) for building the airplane.
  • Reverse Engineering – The workers were given a completed airplane which they could study in order to reproduce the steps required to build it.
  • Mentoring – The “chief designer” built an airplane step by step and the workers replicated each step as it was performed.

The experiment was conducted in two phases. In the first phase, all 8 participants used the Documentation method. In the second phase, one team of 4 tried Reverse Engineering, while the other team of 4 tried Mentoring.

The results were interesting. Using the Documentation method, only one person out of a total of 8 came close to being able to build the airplane at all in the 5-minute period allotted.

Using the Reverse Engineering method, 1 person out of a total of 4 produced a completed airplane in 5 minutes.

Using the Mentoring method, each of 4 team members produced a completed airplane, and in less than the 5 minutes available.

The knowledge transfer bottleneck in software

In a software development effort, knowledge transfer takes place all the time, and it’s easy to imagine a software developer in the “chief designer” role described in the exercise above.

Let’s say I’m a developer who has discovered, and written the code to implement, a technique for binding some data to the controls in a user interface, and that this technique forms a pattern that my fellow developers want to know about. If you were one of my fellow developers, would you rather I (a) gave you a document I had written about the technique, (b) told you where the code was and suggested you figure it out for yourself, or (c) paired with you to implement the pattern for a new set of data?

Now, certainly, pairing with you takes more of my time, and might seem less efficient from my viewpoint. After all, I could be off designing the next pattern, and the one after that. But the  productivity of the team as a whole, rather than my personal productivity, is what’s important. And mentoring helps increase the team’s productivity by avoiding knowledge transfer bottlenecks.

Slow down to boost profits

A team in which everyone works at top capacity has got to be the most productive, right? This article explains why it ain’t necessarily so.

(Note: I didn’t invent the exercise described here. I first saw something like it presented at the Agile2006 conference by Ashley Johnson and Rich Phillips of Valtech Technologies, Inc.)

The assembly line analogy

I recently conducted an exercise with the folks at North Bay Agile in which two teams formed assembly lines for folding paper airplanes. Each assembly line consisted of a number of distinct operations, as follows:

  • Operation 1 – Get raw material (a sheet of paper) from stock.
  • Operation 2 – Fold inward lengthwise, then unfold.
  • Operation 3 – Fold top corners inward.
  • Operation 4 - Fold sides inward, fold in half, fold wings down.

In the first shift, every member of each team worked at top capacity. The result: Each team produced about a dozen airplanes in 5 minutes.

But then I had each team fill out a “profit and loss” statement. They got credit for “selling” all planes produced, but they were also debited for the labor and material costs of uncompleted airplanes (which stacked up in front of Operation 4, the bottleneck). The financial news: Both teams incurred a loss.

In the second shift, the teams were instructed to slow down to match the rate of the slowest operation. This was accomplished by creating a “buffer zone” before each operation and following a rule which said, “you can’t pass your work on to the next operation until that operation’s buffer zone is empty.” The result: Each team still produced around a dozen airplanes in 5 minutes.

When the profit and loss statements were filled out a second time, each team showed a profit. This was directly due to the fact that no work-in-process inventory built up, thus reducing the amount spent on materials and labor.

The most obvious difference in the overall activity of the assembly lines from shift to shift was that, in the second shift, the upstream operations were sometimes idle. By slowing the upstream operations to match the rate of the slowest operation, both assembly lines increased their productivity.

Increasing productivity stepwise

After the first shift in the exercise, the inclination of several participants was to try to find ways to improve the performance of the slowest operation. As the second shift demonstrates, however, a simpler first step is to just slow down all of the upstream operations to match the rate of the slowest operation.

The business novel The Goal outlines a process for increasing the productivity of a manufacturing system:

  • Step 1 – Identify the system’s bottlenecks.
  • Step 2 – Decide how to exploit the bottlenecks (e.g. don’t let a bottleneck be idle).
  • Step 3 – Subordinate everything else to the above decision (e.g. throttle back the upstream operations).
  • Step 4 – Elevate the system’s bottlenecks (e.g. speed up a slow operation).
  • Step 5 – If, in a previous step, a bottleneck has been broken (i.e. a bottleneck is no longer a bottleneck) go back to Step 1.

 As you can see, the recommendation is to slow down all non-bottleneck operations before trying to speed the bottlenecks up.

How does the assembly line exercise relate to software development?

Although software development is not the same as manufacturing, there are situations in development that exhibit the characteristics of an assembly line. Suppose, for example, that you are a developer building components for use by other developers. If you (the upstream operation) produce components at a rate faster than the other developers (the downstream operations) can understand and use them, you can create a bottleneck, causing excess “inventory” to build up.

Software development is about creating and sharing knowledge

Here are some simple things to remember when considering whether it is more profitable to work at top capacity or to be idle part of the time:

  • Knowledge is the inventory of software development
  • People consume knowledge at their own rate
  • Creating knowledge faster than it can be consumed causes excess inventory
  • Excess inventory reduces profits

In other words, working at your own top capacity may not be the positive thing you think it is. If you’re producing software components at a rate greater than the rate at which they can be put to use, you could be hurting the bottom line.

Start at the end

Any software development effort involves the conveying of information, but it’s easy for the important information to be hidden by related (but less important) stuff. Starting at the end is a good way to focus on the information that matters most.

Drawing Maps

In the days before Google Maps, we used to ask other people for directions to places we wanted to go, and often someone would volunteer to draw a map on paper. After taking part in many of these information exchanges, I observed that most people (including myself), when drawing a map, start at the beginning. That is, they start the drawing at the traveler’s point of origin and proceed from there to the destination.

The result was almost always adequate for the intended purpose of getting the traveler from point A to point B, but I noticed that the destination often ended up being crammed into a corner of the page, almost as if it were an afterthought rather than the most important piece of information on the map.

Now it certainly makes sense to draw a map in this fashion. I imagine that the main reason for doing it this way is that when drawing a map we imagine ourselves actually taking the trip we’re describing. We start at the beginning of our imaginary trip and eventually find our way to the destination.  And unless we begin with an inordinately large piece of paper, or are particularly good at allocating space ahead of time, we end up with a map that contains extra information we really don’t need, while details of the destination are omitted because we run out of room.

So I started drawing maps from the end. The first place I put on a map is the destination. From there I work backwards, drawing the streets leading to the destination. Then, if I have room, I draw the highways leading back to the city of origin. The result is a map that emphasizes the important details.

Communicating Technical Information

I’ve noticed a similarity between the way people draw maps and the way they convey technical information. That is, they often tend to start at the beginning and proceed in chronological order to the end.

Just as in map drawing, this approach makes a certain amount of sense. It’s natural for people to convey information in the order in which they discovered or developed it. The communication of the information is kind of a chronological account of the original experience of creation.

The problem is, it’s the end (the destination) that I’m most interested in. I tend to think of the result as the important part, with everything leading up to it being more like “supporting information” which I may or may not want (or even need) to know.

In other words, I tend to get lost in the details of the journey, when what I’m really interested in is where I’m going to end up.

Writing Software

I used to write code from top to bottom. That is, when I wrote a method I would start at the top of the method, and write lines of code in the order in which they would be executed. It made sense, in a way, because I was taught to read and write English from top to bottom. It seemed the natural way to go about it. Unfortunately this approach tended to introduce unnecessary code into the method that had to be stripped out later.

Now when I write software, I like to start at the end. When I write a unit test, for example, I start by writing the assert statement, even if it asserts against objects that don’t yet exist. I start with the assertion, then I see what the assertion requires and I write a line of code above it to satisfy those requirements. If satisfying those requirements introduces new requirements, I write a line of code above that, and so on.

The result is a unit test that carries no extra baggage, no superfluous information, with an emphasis on the most important part, the assertion.

The assertion in a unit test is analogous to the destination on a map. Both are the most important pieces of information. Both make excellent starting points.

Why estimate?

Much has been written on the subject of how to estimate the effort involved in developing software products. Some Agile teams use Story Points as their estimation units. Others estimate in Ideal Days. Still others use one of these plus Task Hours to help refine their estimates. Planning Poker is a popular method for quickly arriving at group consensus on estimates.

My own earliest attempts at estimating predate the Agile era by a couple of decades. In the beginning I used a technique that has probably been tried (with varying degrees of success) by many others:

  1. Break the development effort into as many small tasks as you can think of
  2. Estimate each of the tasks in hours
  3. Add all the estimates together
  4. Apply sufficient “padding” for comfort
  5. Hope the boss buys it

Estimation’s main purpose

There’s no doubt that the more recent Agile estimating techniques are much better than what I started out with, and I’m glad that so much effort has been put into developing these methods. Even so, I believe it’s easy to lose sight of the purpose behind estimating, which can be summarized as follows:

The purpose of estimating is to provide the customer with a predictable development schedule.

Predictable is the operative word here. With a truly predictable schedule, the customer can derive the information that is most important from his or her point of view. Given a predictable schedule, the customer can answer important questions, such as:

  • How much will this development cost?
  • Will we be able to hit the market window?

In other words, the customer is probably not interested in the accuracy or precision of your estimates in and of themselves. The customer is more likely interested in the predictive power of your estimates. Given that, you want to focus your estimating efforts on things that provide predictability.

Duration should be derived, not estimated

I like to encourage teams to focus on estimating User Stories in Story Points, and to discourage them from estimating tasks at all, largely because coming up with Task Hours doesn’t seem to contribute much to the goal of providing the customer with a predictable schedule. Admittedly, estimating Task Hours may help to inform the team about how good or bad it is at estimating duration, but that’s a metric that’s not directly useful to the customer.

What is directly useful is duration that is derived from a team’s demonstrated velocity. Given a velocity in units of Story Points per iteration, plus knowledge of how many Story Points remain in a development effort, the customer can quickly and easily predict the development schedule.

What is “the simplest thing that could possibly work”?

Anyone with even the slightest exposure to eXtreme Programming has heard the phrase “do the simplest thing that could possibly work.” While this precept is typically applied during the process of writing code, I’ve also heard it mentioned during design discussions. I bring it up myself during estimation sessions as a reminder to estimate the simplest implementation of a user story one can imagine.

I’ve also heard it misquoted as “do the easiest thing that could possibly work” and even “do the quickest thing that could possibly work.”

It’s not necessarily the easiest thing

Although the simplest thing that could possibly work might sometimes also be the easiest thing, it often is not. For example, the easiest thing might be to copy and paste a section of code in order to duplicate its functionality in another part of a program. But is that the simplest thing? I believe it is not.

It’s not necessarily the quickest thing

The simplest thing that could possibly work might sometimes also be the quickest thing, but there aren’t any guarantees. The use of short variable and method names might be quicker (because it saves typing time) than the use of longer, more meaningful names, but is it simpler? Again, I don’t think so.

What does simple mean?

Here’s my working definition: Something that is simple is neither complex (meaning having more parts) nor complicated (meaning difficult to understand).

In the first example above, the easiest thing is not the simplest thing because doing the easiest thing (rubber-stamping the code) introduces complexity.

In the second example above, the quickest thing is not the simplest thing because doing the quickest thing (using short names) introduces complication.

Conclusion

If you want to do the simplest thing that could possibly work, look for a solution that is both easy to understand and lacking in unnecessary complexity.

Clicky Web Analytics