Developer's Toolkit

Blog archive

Developers and Productivity

I keep coming back to the topic of programmer productivity for a couple of reasons. First, advances in the economy in general result from improvements in productivity. It is both unlikely and unfortunate if programmers are not also increasing their productivity along with the economy. Second, I believe that developers can do better in terms of productivity than they are today.

Joel Spolksy (http://www.joelonsoftware.com/items/2006/11/10b.html) claims once again that it is impossible to measure programmer productivity. I would agree with him, except that there are some development teams that get things done faster than others. This has even been demonstrable in controlled environments. However, I suspect that Joel means micro rather than macro measurements, even though he cites a fictitious efficiency rating for a company's software development processes. In other words, there is no quantitative way of measuring the speed and reliability by which we are able to produce code.

So my thinking is that productivity improvement is rather like former Supreme Court Justice Potter Stewart's proclamation on pornography – we would know it if we saw it. We know that some development teams are better than others, and we know that some individual developers are better than others (the best and worst are separated by a factor of ten, according to Ed Yourdan), but we simply have no way of measuring and quantifying that difference.

I am not sure how to measure programmer productivity, or if it can ever be done. But I am certain that it can be improved because we have done so for years. Integrated development environments, reusable libraries, frameworks, and better debuggers have all improved the ability of programmers to produce more. This has largely been hidden by the rapidly increasing complexity of applications, and the new application models that developers are required to learn and use.

So we are seeing some progress in programmer productivity, though that progress is largely being hidden by the changing nature of the end product.

I think we can do better. Developers can make better use of tools, whether integrated into the IDE or available outside of the IDE, to write code faster and with fewer errors. Many of these tools can be had for free, especially if they are part of the Eclipse Foundation. In other cases, they may cost a few hundred to a few thousand dollars, but can pay for themselves with regular use.

Most of you cite time pressures as the cause of the lack of tools use. I understand where that comes from, but that simply means that software development management is penny wise and pound foolish. There must be managers out there with the courage and foresight to say that their teams will take the productivity hit for the next month will installing and learning to use new tools, for the long term productivity improvement. The advantages of improving processes, adding automation, and being more analytical about productivity and quality will last far beyond the immediate project.

Posted by Peter Varhol on 11/13/2006


comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube