Productivity in Software Development

Productivity is an economic measure of output per unit of input. Inputs include labor and capital and outputs, in case of software development, consist of new or enhanced software that brings value to external or internal customers.

All projects and organizations (from start-ups to enterprises) have time and budget constrains and to deliver more we need to find ways to become more productive.

 First, let's briefly talk about attempts to measure developers' productivity - from counting lines of code, to measuring functional and complexity points. Lines of code metric was difficult to compare between different languages and frameworks and functional points were to convoluted to use or comprehend. Also, measuring development output in amount of code seems counter-intuitive to anybody with firsthand development experience. If, by using a smart algorithm or improving code re-usability, a developer can solve the same business problem with less code, why we should consider her less productive than a copy / paste enthusiast? A developer who spends time on research of an open source or SaaS solution that can satisfy business requirements could be very productive indeed without writing a single line of code.

Agile & SCRUM popularized the concept of Velocity and some companies attempted to use it to measure team's productivity. There are multiple issues with this approach:

• You cannot compare velocity between teams
• Any changes in team's composition will cause a change in velocity
• Management attempts to use velocity as the productivity measurement inevitable lead to system manipulation and point inflation

 Velocity is an internal measurement for the team to assist in a capacity planning. Let's leave it at this.

 Very attractive approach on the executive level is to tie productivity of development organization to company's financial results. While there is definitely a correlation, it is an indirect one and could be difficult to quantify. There are too many factors outside of the development organization control. For example, performance of sales or marketing teams or market conditions. And, as Martin Fowler points out, there is a time lag, especially in large organizations – it can sometimes take months or years to see real financial results from an IT project, or from productivity improvements. What you are developing this quarter is unlikely to affect financial results at the end of it.

 Despite that we all "know" who are the best developers on the team and can "easily see" which team is kicking ass and which one is struggling, the software industry has so far escaped many attempts to measure productivity in an effective, precise, and reliable way.

 Though, let's not despair. While there is no reliable way to measure productivity, there are many proven ways to enhance it.

 In this blog series, I will examine different aspects of productivity in software development and how to improve it on individual, team, and organization levels. I will also review pattern & anti-patterns that affect productivity in each case.

In next post I will discuss productivity on a developer level.