The BEST Way To Measure Software Developer Performance With Dr. Nicole Forsgren
ฝัง
- เผยแพร่เมื่อ 1 มิ.ย. 2024
- Can you really track developer productivity? How do you assess software developer performance using developer productivity metrics? Are DORA metrics the best way to go?
In this clip, Dr. Nicole Forsgren, author of 'Accelerate' and one of key figures in the DORA movement, talks to Dave about some of her work and how science and engineering has taken hold of the software industry.
You can listen to the FULL podcast HERE ➡️ open.spotify.com/episode/3QiW...
-
🗣️ THE ENGINEERING ROOM PODCAST:
Apple - apple.co/43s2e0h
Spotify - spoti.fi/3VqZVIV
Amazon - amzn.to/43nkkRl
Audible - bit.ly/TERaudible
-
🙏The Engineering Room series is SPONSORED BY EQUAL EXPERTS
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
-
#softwareengineer #developer #developerproductivity - วิทยาศาสตร์และเทคโนโลยี
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.
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
I don’t totally agree. To me this is a bit like saying the best footballer is the one who makes the best passes into the scoring area. But some are defenders, some strikers, some are great at set plays. There is no single “best way” to measure engineers. Some engineers are great at mentoring and idea generation. Some engineers are great at developing effective architectures . Some are great at code reviews and tests. Some are security focused. It is about having the right mix in a TEAM. In general, I do not believe in measuring individuals, I believe in seeing how well teams do.
It starts as a business process and it ends as a business process, but the core is Technical, a collaboration will have to emerge by someone or a group of people that understand both, that's why small companies outperforms big ones, it's those people that just works well.
Movie making is a great example of multiple people each with different expertise that collaborate to create something, the famouse teams stay together and they build their fortune because of it, we don't have that necessarily in Software, but we should.
Put yourself in the shoes of the business. Developers are hired as an investment to produce outcomes. Imagine you spend $100k per month on a team, and they don't produce fast enough to increase sales or beat competition. When you ask why, they say "You shoul measure us based on how nice we made that date picker, or how we refactored some old code".
@@JamesSmith-cm7sg that might be a failure of business as much or more than development. Productivity is a hard thing to measure in a useful way.
@@TehKarmalizer The best developers I have met never use business as an excuse for their performance: they know they are part of the business, and they know they have to work with others to perform well and have a nice environment. The "us vs them" mentality has never made a team great.
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.
My best day as a programmer was merging a branch that deleted half a million lines of code. It was obsolete, unused, or just plain crap stuff.
I guess I’m really unproductive…
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.
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.
We improved the throughput of Jira tickets by making the tickets smaller. Improved productivity!
Great chat, have followed Dr Forsgren's work for some time
Glad to finally see a podcast with Dr. Forsgren
continuous delivery meant continuous status update in every org I joined. I haven't met anyone who enjoys it.
Then you have never worked in an org that practices "Continuous Delivery". CD means working so that you keep your software in an always releasable state. The measurable results of working that way is more efficient, higher-quality and the people making the software having more fun.
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?
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.
The most important and completely impossible to test for components of excellent software are curiosity, imagination, and creativity.
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.
Like the Dune based T-shirt at the end
why do we need to?
Dave, come here. Closer. Closer. Even closer. Listen... and I say this with all the love in the world... we need to talk about that shirt you keep wearing...
Check the description for the link and discount information and you can get your own 😎
Easy. Engineers' productivity is the inverse of amount of managers overseeing them.
People behave as they are measured
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.
But why should I?
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.
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.
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).
This is only one metric out of four, separating them as indicator of performance will lose any value of these metrics.
I like to look at them as part of more indicators of progress or not. I will look at the principles and values of your team first. From this you can start to use indicators to measure. You define the why and after the how and what. for example, engineering principles could be Twelve factors, CD and Agile. You could add some business values such as customer centricity and product/services as self-service. From their you can start to draw indicators to use to measure your progress for example adding a customer satisfaction survey (NPS form for internal stakeholders). A lot to say 🙂
@@patrickrodies6111 time to market for the end user. Not time from first commit to production.
Following scenario. I deploy 4 times per day with tiny changes and most likely various refactorings or once per day or even every second day. Am I now an unperformend org? What matters more is, that i am able to deploy any time. Of course split the working packages as small as possible.
I see it like with microservice movement, things went a bit too far. Those metrics are okay when you do not put them as goals, just as a healthcheck. Some days i deploy more often per day, some days not. Depending on the uncertainty and complexity of the problem domain.
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...
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.
Let's get the developers gaming the system that measures them, rather than concentrating on developing 🙄
The best way to measure is amount of code deleted or how much you get done with less code.
And how do you measure the following "how much you get done"?
If you use that everyone will just stay using single letter variables again
I just deleted the repo - so many deleted lines of code! What a productive week 😁
@@toonsoffun5733 Whatever sells and makes money
@@elliottmarshall1424don't count characters, count "logical atoms"
She's definitely a Theory X person who will destroy a company via Goodhart's Law
If you dont measure you cant improve 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. 😂😂😂😂
Do customers care about response time or resources? I don’t think so. You could probably halve the response time of TH-cam from what it is now, and use 10x less compute and no user would care.
As to software using as little resources possible is a company goal? Perhaps in some very specialised fields, but I would argue that 99% of companies don’t care very much about resources used by the software. Like, I delivered software for FX traders for 15 years, not once did anyone ask how much the AWS bill was, because it was 1% what they paid the engineers and 0.1% what they paid the traders. They care far more about the Human Resources needed to deliver their functionality as fast as possible.
@@MrShikaga As a user, I will any day take an app with a fast response giving you a reasonable value over a sluggish app boasting twice as much value.
@@Exiide89 absolutely agree. Your app can’t be sluggish. But my point was that people don’t decide based of “fastest” which was the original assertion. It needs to be fast enough to give a good user experience, but after that, whether the page loads in 30ms or 5ms doesn’t matter. People don’t take a website that loads 6x faster if the response is already faster than their mind can comprehend. There are a very small number of applications where “fastest response time” is a determining factor for users, such as writing High Frequency Trading applications, but this would be less than 0.1% of software written.
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.
She's got the dead eyes of a serial killer.