Musings on Software Productivity

Though I cannot remember the exact source, I have heard it enough times that I am sure it’s not a figment of my imagination, the assertion that software productivity has not increased significantly in the past two decades. That the number of lines of tested and debugged code written per day per developer is roughly the same as two decades ago. 

I find this an astonishing statement that is in one sense possibly true, the number of lines of code per day part, but in another sense patently false, that lines of code per day is a valid measure of developer productivity. 

My point being that measuring lines of code written is not a valid measure of relative productivity at all. That it might take just as long to write a line of solid code as two decades ago, but that one line today does orders of magnitude more than what one line of code did two decades ago. So what we should be measuring is not lines of code per day, but something like the number of assembly instructions per line of code (per day). 

I am of that certain age that I actually had to learn assembly level coding. I vividly remember the painful effort (punch cards and all) it took just to get the idiot machine to add two numbers. Move some number into some register, move another number into a different register, add the contents of these two registers into a third register. Just this simple task usually took, without setup code, 20 lines of code, not to mention you usually had to represent the number you want added in binary or hexadecimal.  

Now compare this, to the following lines of XAML code for creating a UI object in a WPF application that prompts for someone to enter their last name:

<label> Grid.Row="1">
   Enter your last name:
</Label>
<TextBox Grid.Row="1" Grid.Column="1"
   Name ="lastName" Margin="0,5,10,5"/>

These 5 lines of code invoke thousands of assembly instructions, yet take only minutes to write. I know I am cheating a bit here, the XAML segment actually leverages quite a few run time libraries from Microsoft, but this is my point exactly. 

The reason why we the argument that software productivity has not improved over two decades is that whoever was measuring productivity was measuring the wrong thing. They should not count the lines of code written per day, but the amount of actual computer instructions these lines of code generate. 

If this is our measure, then software productivity has sky rocketed over the past two decades. If I were to even try to write the equivalent assembly code to the 5 XAML lines, it might be months in not years to get this working to the same level of behavior and function (remember that MPF apps now how to realize themselves, leverage GPUs, render true type fonts, etc.) . The reason why productivity has so vastly improved is not the speed of writing lines of code, but the power of leveraging lines of code already written. High level toolkits, software components, libraries and languages make programs we take for granted today possible. 

So if we consider lines of code written per day as the measure of software productivity, yes we are just as slow as two decades ago. However if we consider what these lines of code actually do, the assertion that productivity has not changed is just plain wrong.