Insomnia Consulting Still searching for an interesting slogan

The OnProductManagement blog peaked my interest with this entry (http://bit.ly/fItET). In the blog, Alan discusses the mandates that most VPs of Engineering are faced with. The point of the article is to look for a similar mandate for Product Management, but I'd like to focus on the engineering mandates. The first of these is "Increase Speed of Delivery".

Measuring the productivity of software developers is a complicated undertaking and it may not be exactly the same thing as "Speed of Delivery". There is a wide range of opinions on what constitutes productivity. Productivity of a team is likely more important that the productivity of an individual. So let's examine some thoughts on performance measurement and how it might be considered in a real-world example.

Raganwald, in his blog entry (http://bit.ly/cv6pJ), captures some thoughts on the difficulties of measuring productivity and the inaccuracies of the measurements. There are two ends of the continuum when it comes to measuring productivity: Engineering measurements and Profitability measurements. Engineering measurements are too specific to address the full spectrum of developer productivity, but as a concept it gets at the core thought that productivity is a function of how much material a programmer generates, or how much "work" s/he accomplishes. Profitability measurement views productivity as a function of business output, regardless of how much work is completed. I discussed these in a little more detail here (http://bit.ly/43NFGw)

Formulating the idea and then translating that idea into code are the dual components of a productive software development process. Profitability addresses the shortcomings in the first part. Many times, software development teams are working with badly formulated ideas. Cranking out code at a furious pace only to find they are solving the wrong problem. When profitability suffers, the productivity of the software development team is diminished.

Translating the ideas into code is fundamentally an engineering problem. But what does management mean when it mandates "Increase the speed of delivery"? Obviously, higher-level management is interested in engineering's capabilities to generate artifacts that can yield a return. It's impossible to turn an engineering metric into something useful if the formulation isn't mature enough to feed useful ideas to the engineers. Then it's a matter of turning those ideas into software. The ideas become "blueprints", the blueprints become code, and the code becomes executable, optimized, refactored, deliverable software.

Recently, for an application I was working on, the product backlog contained two features to be scheduled for the next release: "Add OpenOffice integration" and "Create the ability to add multiple emails for a customer record". Superficially, OpenOffice integration seemed much more difficult. Adding multiple emails would be primarily a datamodel problem, with a couple UI changes. OpenOffice integration meant touching the application anywhere our home-brewed word-processor was already utilized, learning the OpenOffice API and designing the entire integration "feature" from scratch.

Both projects took roughly the same amount of time. The OpenOffice integration is flashy and will likely add more customers to the pipeline. Multiple email was requested by a lot of existing customers. It was difficult to implement because of some existing design decisions, took much longer than originally expected and probably will not be notable in the sales efforts.

Metaphorically, the efforts are akin to digging holes in soft sand vs hard packed soil and rock. The programmer working on the OpenOffice integration can create more lines of code, more function points, more ANYTHING by most engineering definitions and will have created more utility for the product and likely created more profit for the company. The programmer doing the multiple emails will have spent most of his time trying to understand existing code, making small changes to existing classes and testing that the changes made in the application did not cause regression defects.

This quote from Joel Spolsky is especially relevant; "Essentially, design adds value faster than it adds cost." (http://bit.ly/KXsVt). This goes hand in hand with the concept of turning ideas into software; it's the ideas that are crucial. For speeding delivery, we're talking about making it easier to do just that. It isn't about productivity while the programmer is banging on his keyboard, it's about the decisions leading up to the point where a Product Manager says "Make this so". Speed of Delivery will depend on the history of decisions up to that point more so than the individual programmer's ability to sling code.