In my last post I made light of the constant desire of (some) developers to want the latest and greatest in hardware; it can never be good enough. Smart managers know there is a balancing point between having the right tools to increase developer productivity and throwing money in the wind.

So exactly how do you justify and quantify the benefits of using faster tools in development?

The Business Case

Part of a manager’s role is to make the most profit for the company as possible while keeping customers happy. The other part of their role is keeping developers as productive as possible; and this fortunately means (usually) happy too. Whether you are building software for internal use, software for a customer or  a product for many customers; the goal is to get as much software capability for the least amount of cost. Hopefully, you are also thinking long-term supportability and upgrade too.

The developer’s role is to build the best possible software as fast as possible and for the least overall cost.

The problem? How do you really measure developer productivity increases due to better tools?

You can look at the burn-down rates on user stories before and after. The problem with that though is that estimates are based on current capabilities. The team’s ability to estimate and then complete work during a sprint automatically adjusts to accommodate new tools and processes; after all that is what agile development is all about.

Lines of code is a useless measure for productivity. It is more about the right lines of code than quantity unless you want to encourage developers to write inefficient code.

The best way I can think of to determine developer productivity and conversely, developer bottlenecks is “observation”. Get out of the office and go watch developers do their work in as close to a real setting as possible. Make notes.

  • How often do they switch contexts? Windows?
  • Which windows/tools do they use the most?
  • How long does it take to check out a project? Check-in a project?
  • How long does it take to run a build? Unit tests?
  • Are some of these tasks done in parallel or do they require a pause while the task completes?
  • Etc.

Then discuss the bottlenecks with the team. Where are the biggest time killers and frustrations? Is the task that takes 10 minutes twice a day more or less wasteful than the one that takes 30 seconds, 10 times an hour? Consider the impact on flow too. If you are waiting too much time when you are on a roll then you can lose the flow by having to wait.

Consider moving tasks that require a lot of horsepower, but not very often, to a server environment that can be shared by the team (continuous integration, etc.). It might make sense to optimize for the specific problem.

Sometimes the vendor of your developer tools will force your hand through increased hardware requirements.

So now you know what problems you are trying to solve and can make legitimate business decisions around where to spend money.

If you can give your developers an additional 2-5 minutes per hour, that translates to something like 50 to 125 hours in a year. Of course don’t forget to subtract the realistic time it takes to load all of your tools and configure your new development environment.

All this assumes of course that you have additional paying work for them and that they are actually focused and not distracted in the first place.

If the developers are constantly interrupted by things like social media, e-mail, text messaging, and instant messaging, there may be few realized gains. The same holds true for meetings and other corporate distractions.

Ultimately, the best work gets done when teams can focus for solid periods of time without distractions; including waiting too much for slow hardware.

The Perception

Increasing productivity may not be a direct business value. Perhaps the productivity gains will not offset the cost of better (more expensive) equipment. Perhaps there are other factors.

But the remaining thing to consider is the perception of the majority of your developers. Do they feel they have adequate tools to do their job? If so this can lead to job dissatisfaction and higher than normal churn.

This will impact your bottom line too.

Conclusion

Developers and management have to understand each others’ concerns. Management needs to help developers remove bottlenecks and roadblocks so they can focus on developing great code. Developers need to be constantly looking for ways to improve things and increase their productivity; delivering real business value.

And the two camps need to understand, communicate openly, respect and help each other. Us and them doesn’t work anymore in today’s fast paced world, especially in the technology world.

Great development is both a business and a development function.