The BEST Way To Measure Software Developer Performance With Dr. Nicole Forsgren

The best way to measure is amount of code deleted or how much you get done with less code.

continuous delivery meant continuous status update in every org I joined. I haven't met anyone who enjoys it.

A software giving desired output with fastest response time using reasonable amount of resouces is a user's objective.
A software using least amount of resources giving a reasonable output with a reasonable response time is a software company's objective.
Software engineer is the donkey being whipped by both sides. 😂😂😂😂

Put time pressure on software developers and you get worse code.
Worse code means less maintainable and adjustable code.
Means in the long terms costs more money/time.

But most companies look at how fast a software developer can deliver something.

I think best way to measure a software developer is:
- how much good input/ideas does he/she bring to the team
- how good is his/hers team work and his/hers help teaching/guiding juniors

Where I work the dev manager was excited to announce the Git Lab would be introduced. Now he said "we can measure the productivity of the engineers, so make sure you commit lots of code every day".

There you go Git a micromanagement tool. What happens when everyone who is now in fear of their job, push to production and cut corners as much as possible to avoid being fired.

why do we need to?

In my humble opinion. A good software is the outcome of the complicated process so it make sense for the measurement of it is complicated also.

Lifespan efficiency to user value seems to be something you need to calibrate regularly. It took a couple days of automation analysis (script vs ansible) to conclude that automating Maint was less value than manual Maint - because the app should be sunset before the next Maint cycle - it simply wasn’t worth automating.

I think what we're going to see is nudging of developer efficiency metrics in ways that will make tools like Github Copilot seem more useful than they are. I've heard many claims of making developers 50% more efficient but having tried to use it for years I struggle to think about how that could be true except in situations where you're very low skilled in whatever you're trying to do. I'm sure it could make me 50% more efficient at the coding part of problem solving when I'm learning a new language but it tends to lower my efficiency in most areas of work that are more important than coding.

Easy. Engineers' productivity is the inverse of amount of managers overseeing them.

I think a key differentiator is where the drive for approaches like Continuous Delivery is coming from. If it's from developers empowered to remove barriers to them delivering better code faster, then it'll be motivating. If it's an edict from on high that all these competitors have shorter cycle times, so we're going to expect the same even though actually changing the tooling and processes is a low priority, it'll lead to burnout.

Great chat, have followed Dr Forsgren's work for some time

You’ll get an improvement in the things you measure, so be careful about the things you measure. If you measure lines of code you’ll get more lines of code, if you measure time at the computer you’ll get more time at the computer, if you measure bug fixes you’ll get more bug fixes, if you measure less bugs you’ll get less bugs. But you may not get the outcomes you expect.

Developers are increasingly being treated like cattle, especially by large companies and platforms. It is therefore only logical to measure their performance as accurately as possible, as it may be better to replace one developer with another. Our luck is that the labor market is currently still more on our side, but at some point this will no longer be the case...

Glad to finally see a podcast with Dr. Forsgren

Let's get the developers gaming the system that measures them, rather than concentrating on developing 🙄

Godharts law - Managers these days know about DORA and so their teams or even engineers have to deploy multiple times per day.
Engineers are getting measured by deployment frequency. Output != Outcome.

I think CI is not the reason for burnout, those are bad managers adding DORA metrics as goals.
Time to market matters the most (also from the end-user perspective).

The best way to measure is money in. All the clean code and architecture bullshit was made up, so we have “important sounding” stuff to say to our managers, who are proficient in bullshitting.

If you spent time on your business and it didn’t earn more money means you wasted time.
It hits you very hard when you try to go solo.

IMO there’s no one single but multiple metric to take into account. And some are not easily measurable like the ability to work efficiently within a team. This one requires listening ability, sharing ideas without being polluted by dogmas, positiveness but with the ability to talk constructively about the issues (technical or organizational).
In a simple word: to be open minded.
It also means you’re able to not be stuck in your habits and also again not being dogmatic to be able to be pragmatic when needed.
All of these can’t be covered by metrics, you can only have a feeling on it.
Also, when working within a team you cannot measure individuals on the base of the outcome (the overall code, the deliverable), you can only measure the whole team also with the influence of the organization. So we maybe shouldn’t try to measure it else there’s huge change to misinterpret the results.

Maybe the only thing that worth to be measured it the time needed to provide a new feature and compare it with previous measures in order to see if you took the right choices to keep the code base evolutive while the complication increases.
And even in that case you will maybe have to exclude some parts of the development in order to not start to measure something else, like integrating other team services as you could spend lot of time in communication and coordination due more to organizational stuff than solution implementation.
What do you think?

All corporate developers have a terrible performance. People like to negate the existence of the "10x programmer" (hilarious). But they comically fail to acknowledge that often the people who started the company they now work were 100, 1000x more productive programmers they are.

continous integration is when I started to hate this career choice - oh I love software dev but when Iook back it was more exciting pre CD and agile days. Today's CD mantra feels like a never-ending conveyour belt of crunch and misery. Are there worse jobs out there...sure - but this aint what it used to be. Finally to add all Burndown charts are evil.

The most important and completely impossible to test for components of excellent software are curiosity, imagination, and creativity.

Measure anything well... In it landscape where technologies, frameworks, classes, libraries getting obsolete on quarterly basis and it training time given to developers are 0 h per year and make developers compete with developers from india and uzbekistan where life is cheaper... And migrating jobs to india massively. Also- what a surprise - 3/4 of office is from asia.
So keep talking about measuring.

She's definitely a Theory X person who will destroy a company via Goodhart's Law

But why should I?

She's got the dead eyes of a serial killer.

There are quite some interting aspects to this talk. First of all, Craftsmanship is a good thing. I think that it is very important to mention this and why: Developers should be perceived as experts in their field (which is not only coding alone), and who know their tools across the whole spectrum of what it involves. This includes quality standards and educating themselves and others, even organizing themselves based on their profession. It is not really like that nowadays IMO, but it should be. So such a "movement" is good, both for the professional individual and for the customer or organization.

Of course measuring and transparency of work and technical systems, at least for the ones who are building those, is essential. Otherwise you are doomed for failure or mediocrity and you will fool yourself and others with vague assumptions. It does not require much intelligence to undestand that a scientific view of the world with transparency, feedback and facts is needed for results, let alone good ones. The craftsman who does not understand this is not a good one. For example, who would want an electrician to make a large installation without measuring anything? Measuring and feedback based on facts is quite naturally a part of being a good craftsman.

So being an "engineer" and being a "craftsman" are both important attributes of the same profession. There is no contradiction. A dogmatic view of the world is not helpful here.

Measuring by itself is also not useful at all. Like craftsmanship, measuring is a means for a purpose. What and how to measure and how to interpret the results always has a (limited) context and is based on a goal what to achieve or what to understand. The same is true for applying skills and techniques as a craftsman in a self-responsible way to achieve good results that match requirements and customer needs. Understanding those and repeatedly "measuring" if you are still on track is part of the activity.

Software is only useful and manageable when it it deterministic. The same is true for the software development process, or how else would you know when to deliver what in a working version which satisfies the customer and the requirements? That is essential to the profession. Normally, this should aid the sanity and mental health of professionals, or otherwise there will only be harmful "confusion" and unnecessary pressure.

It is important to understand though, that these metrics and techniques are "private" to the activity. They have a limited scope. An organization has its own metrics, while it also is less deterministic, because there are just too many variables and contradictory interests.

The problem comes when those contexts are confused or mixed, meaning: misused. That creates only problems and unnecessary stress. Metrics in the context of software development have no meaning in the context of an organization. If interpreted from that perspective it only results in a disrespectful view of the profession and people, whether it be an "engineer" or a "craftsman". This type of thinking is harmful for everyone. It is important to understand where the real pain is coming from if it is there.

We improved the throughput of Jira tickets by making the tickets smaller. Improved productivity!

Goodharts law is real and known.
Once we start closing the loop on business objectives and measure against hypothesised value we will see the real mirror of the software we launch. Flow and Dora metrics are useful but measure throughput, work type and quality. Neither actually close the loop on value I.e efficiency, debt risk reduction or business value.

If you dont measure you cant improve it!

Like the Dune based T-shirt at the end

People behave as they are measured

we as a team of 5 were really great at collaborating and adding new features to the product. all was great until some high manager decided to ditch team's KPIs and replaced it with IC quarterly review. No more team work, collaboration, learning together as each individual is measured by HIS/HER number of commits and how long does it take for him/her to implement assigned at the start of the sprint ticket. It's sickening, and I truly started considering quitting and starting on my own. It's not first time that some dumb decision (hello McKensey) destroys working environments.

Clickbait

Given humans game rules, ensure the side effect of the rule is a desirable outcome.

Consider PR (pull request) cycle time, if this is gamed PRs become smaller. Value of small changes is very easy to articulate, or the PR is scrutinized.

Developers really appreciated the positive side effects. This also contributed to smaller more focused stories.