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 ( 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 at 1:15 PM

comments powered by Disqus


  • Visual Studio Code Dev Team Cleans Up

    The Visual Studio Code development team focused on some housekeeping in the October update, closing more than 4,000 issues on GitHub, where the cross-platform, open-source editor lives.

  • ML.NET Model Builder Update Boosts Image Classification

    Microsoft announced an update to the Model Builder component of its ML.NET machine learning framework, boosting image classification and adding "try your model" functionality for predictions with sample input.

  • How to Do Naive Bayes with Numeric Data Using C#

    Dr. James McCaffrey of Microsoft Research uses a full code sample and screenshots to demonstrate how to create a naive Bayes classification system when the predictor values are numeric, using the C# language without any special code libraries.

  • Vortex

    Open Source 'Infrastructure-as-Code' SDK Adds .NET Core Support for Working with Azure

    Pulumi, known for its "Infrastructure-as-Code" cloud development tooling, has added support for .NET Core, letting .NET-centric developers use C#, F# and VB.NET to create, deploy, and manage Azure infrastructure.

  • .NET Framework Not Forgotten: Repair Tool Updated

    Even though Microsoft's development focus has shifted to the open-source, cross-platform .NET Core initiative -- with the aging, traditional, Windows-only .NET Framework relegated primarily to fixes and maintenance such as quality and reliability improvements -- the latter is still getting some other attention, as exemplified in a repair tool update.

.NET Insight

Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.

Upcoming Events