What is the ROI to the company for developer tools? This has always been and continues to be a struggle in any development organization. Developer productivity to date has been very poorly measured and studied. Programming has always been a creative task bound within the constraints of a framework. Many people have tried to measure direct individual developer productivity with less than convincing results:
Bugs per dev, bugs per team, bug regression rates, bug trend lines, comparative .NET Framework book sales rates, # of [static analysis] violations per kloc, etc, etc.. the list is really endless…
So when it comes to assessing the value of development tools, what are the motivational and productivity drivers? During my time as a development manager, my focus was always on reducing roadblocks and mindless repetitive tasks. When you are well compensating developers to use their grey matter, you don’t want their efforts to be wasted on the simple stuff.
Focusing on a bottom-up approach, I base the tool choices on the marginal cost for adding a developer. After getting the basics out of the way, including corporate overhead, dev box, standard software load and a complier, what’s next?
Well, there are a plethora of vendors all screaming at you to buy their product, but let’s take a step back and look at what makes a developer produce better code.
Here is my list in order and why. It starts at the developer desktop and depends on frequency of use and then spreads out to the rest of the development team:
- Source control (with nightly backups) – Even for a development team of one, don’t leave home without it. The benefits of source control really can’t be overstated: revision control, easy diffs, build integration, product branching and maintenance, etc.
- static analysis – like grammar checking for Office but so much deeper. It has been proven time and time again that getting rid of the minor flaws and style inconsistencies right when the developer is working and the code is fresh in their brain is the most productive. Waiting 2 hours, a day and for some even a week costs a context switch. When you add in the regression analysis for the maintainability, this tool just shines and pays for itself quickly
- Issue tracking – some might debate that this tool’s placement should be above static analysis, but as I said, my focus here is on the developer’s desktop and not team or management needs.
- refactoring – only sightly better than find/search/replace – not essential but when used frequently and consistently can be used for good productivity benefits . It’s one of the small tools that get you through the day.
- code review – similar to static analysis but now we have widened our view off of the desktop and include the team to build better code. No one person can know everything and extra pairs of eyes on the code is only going to make it better.
- unit testing – anything to take away the drudgery of building simple test cases that completely cover the class/api interfaces and maintaining with the refactoring that will happen over time. You might ask why unit testing is lower on the list. Simple. You can’t test code that has not been written yet.
- dynamic/performance profiling and input injection – your customer will like you for this one. Over time, most applications grow, add new features and become sluggish pigs. Version performance testing and making critical judgments in trading off performance for value is one of the keys to repeat customers.
There you have it. A list of tools for developers (note I said developers not PMs or teams) that I consider essential to have on each desktop to get them through their day.