About productivity and SLOC
The problem with SLOC
The problem with the SLOC metric is that it measures an approximation of the quantity of code written, without taking into account:
- the quality of the code (i.e. what if for every 100 SLOC you have to add another 90 SLOC because of bugs, but that you don't know at the moment your code is delivered ?)
- the goals reached with the code (i.e. do the 10K SLOC handle all the expected use cases or user stories ? or only a tiny subset ?)
- the maintainability of the code (i.e. will you have to add 1% or 50% more code for adjusting the code to expectable evolving requirements ?).
Otherwise stated, the production of error prone unmaintainable spaghetti code with lots of copy-pasted parts will be considered as more productive than carefully engineered reusable code.
So SLOC is definitively not the best way to measure productivity.
What productivity are we considering ?
Productivity is measured for a process. So SLOC could be a perfectly valid indicator for the coding process alone.
If for instance, you misunderstand poor requirements, spend five month to produce the software, show it to the user, discover that it's plain wrong and spend another 5 month to rewrite it for good from the scratch, you would have the same productivity in SLOC/month, that a team writing the code right at the first time, for example because they used an agile process that reduces misunderstandings through frequent feed-back. This apparent equal productivity hides huge problems.
So, measuring software development productivity needs to take into account the whole process, including analysing requirements, designing what to code, coding, testing, debugging, and verifying that user expectations are met. As all these activities are very different, the best thing is to measure the only think that matters: working software, i.e. what the software produced means to the user.
How to measure software deliverables ?
Several approaches exist:
- The typical approach in classical software engineering is Function Points (FP). Function points are measured based on the requirements to fulfill (e.g. number of forms, number of fields in each forms, etc...). Productivity is then measured in FP per unit of time and per person. Some companies even have data that telling how many function points a developper can produce per unit of time in a given language for a given domain. The problem with FP is that it requires very detailed requirements upfront and it's time consuming.
- A more modern and pragmatic approach is story points(SP). These are used to evaluate the complexity of the code to be produced, and are routinely used for evaluating velocity of development teams. However, SP is an estimation measure for work performed before all the details are known. It's not a final measure of what actually happened. So some care must be taken when using it as a productivity measure because it could backfire on the estimation process.
About productivity of static vs. dynamic typing
I have to confess that I'm personally a fan of statically typed languages, because in my inner self I know that it's more reliable (years of coding proved me that).
So one thing that I take for sure is that statically typed language are able to prevent much more errors/bugs at compile time (e.g. typos, mismatch in the expected types, etc...) than non statically typed languages. But in all objectivity, I wouldn't dare to abusively generalize this as a higher productivity.
Is your architect right ?
Maybe, maybe not.
But his arguments do not seem valid: the productivity gain of statically typed language comes from a significant number of errors that are caught upfront by the compiler.
Consequently it is not possible to find out this "higher" productivity gain by looking at SLOC alone without looking at the rework required for dynamically typed languages. So his comparison can't be fair.
The argument of comparable circumstances does not hold either. Some dynamically typed languages allow some higher level constructs that require less code than doing the same in one of the classic statically typed languages. So you could need less time, write less code, but add the same analysis, testing and verification overhead. So measuring the productivity by the SLOC would dilute the potential productivity gains, thus creating a bias against dynamically typed language.
Any study to support that claim ?
Several recent academic studies exist on the topic. Although some of them see an advantage of static typing, it's in general limited to a specific purpose (documentation, reuse of poorly documented code or API, etc..). Prudent wording is also used because modern IDE have significantly reduced the risks related to dynamic typing: