Developer Productivity & Metrics

Is your team always missing deadlines? Have you considered why? How do you know how productive your developers are?

Lines of code used to be a common metric, but it's easy to add loads of comments, white space and make methods much longer than necessary. This can of course lead to bugs in code and technical debt.

What about points, or reopened bugs, or code churn?

Focus

It's nice to focus on one small sprint at a time. The reality is that one project might have ended, only to have some issue pop-up or it to overrun and the next project might've already started. The Project Manager can't say no, or there is a lack of change control so the project spirals. Unfortunately, that's the way it is sometimes.  Focussing on one project at a time sometimes is not possible, although switching from one to another in not an efficient way to work ( https://www.infoq.com/articles/multitasking-problems).

Outside Factors

There are also many factors that slow down your team. For starters, crappy equipment. Do you still have a spinning disk that’s slowly wearing out? I have! I benchmarked it last week and it was 54,000% slower than an obsolete Samsung Evo circa 2015. I wrote about this in 2015 ( https://www.dombat.co.uk/the-insanity-of-underpowered-developer-machines/) and it still confuses me why a company thinks saving $1,000 on a decent laptop saves them money.

The lost productivity will be costing many times more than that.

So how do we measure developer productivity?

Ultimately, it's the delivery of high quality, working software.  It doesn't have to be over engineered or include the latest shiny technology. As long as it meets or exceeds the customer’s needs, is on-time (or early) and makes money then that will have been a great bit of work. You don't need to count lines of code to know that.