DON'T EVEN TRY to Measure Developer Productivity. Do This Instead

No video

DON'T EVEN TRY to Measure Developer Productivity. Do This Instead - 7 Strategies

Рет қаралды 859

2 ай бұрын

Think you can measure developer productivity? Think again. In this video, David Scott Bernstein challenges conventional wisdom and reveals why traditional metrics fall short. Instead of focusing on misleading measures, discover seven powerful strategies that truly capture the value and effectiveness of your software development process.
Curious about what really matters when it comes to measuring success in software development? Wondering how to avoid common pitfalls that lead to higher bug rates and lower quality? Click play to uncover these essential insights and transform the way you evaluate your team's performance.
Traditional metrics often fall short. In this video, David Scott Bernstein unveils seven innovative strategies that shift the focus from misleading productivity metrics to what really matters in software development.
Discover why common practices like measuring velocity can be misleading and what you should focus on instead. Learn how to identify the key metrics that provide real insights into your development process and how to use them to drive improvement.
Curious about the metrics that can revolutionize your approach to software development? Click play to uncover these essential strategies and transform the way you measure success in your projects.
Software Developer Training and Resources:
- Explore comprehensive courses on software development principles and practices at To Be Agile: ToBeAgile.com
My Developer Essentials Training curriculum shows how to build software using design patterns, refactoring, and test-first development. Contact me (tobeagile.com/...) if you have a group of ten or more software developers and are interested in a private class. If you or a few of you would like to attend one of my public classes then join my mailing list on my Public Training Schedule (tobeagile.com/...) and Iwill notify you when registration opens for next public class.
- Deepen your understanding with my book, "Beyond Legacy Code: Nine Practices to Extend the Life and Value of Your Software": BeyondLegacyCo...
For AI Enthusiasts:
- Master prompt engineering with "Prompt Engineering for Everyone: A Comprehensive Guide to Unlock the Potential of ChatGPT and AI Language Models". Get your copy on Amazon: www.amazon.com...
Next Video in the Series:
- Check out my channel, @ThePassionateProgrammer for more videos -
/ @thepassionateprogrammer
Your Thoughts Matter:
- Have questions, suggestions, or ideas? Share your thoughts in the comments below. I'm excited to hear from you!
#ThePassionateProgrammer #DavidScottBernstein #SoftwareDevelopment #AIPromptEngineering

Пікірлер: 12

@bernhardkrickl5197 Ай бұрын

Pretty close to the DORA metrics, which are backed by sound scientific studies and shown to improve development.

@ThePassionateProgrammer Ай бұрын

Thank you.

@GeirGulbrandsen Ай бұрын

Thanks David, that's an interesting list. I'm not immediately sold on the value or reliability of Defect Density, and I don't feel it fits with the rest of your list. Firstly there is a problem of construct validity; what exactly is "a defect", what's the unit of measure for "a defect" and how can you compare one defect to another? Would it not be more useful, and easier to compare, something like how much time is spent fixing defects? That would cover misunderstandings, miscommunications, implementing the wrong ting, or the thing wrongly, as well as mistakes in code. This would also tie in well with "Time to value", "Time spent coding", and to some degree play along with "Efficiency of feedback loops".

@ThePassionateProgrammer Ай бұрын

Great points, I totally agree. Time spent on defect mitigation is a far better metric than defect density. Thank you!

@sindhal6250 2 ай бұрын

I would have loved you adding the _reasons_ why we should create and monitor these performance indicators, how and what do they tell about development and how to address those issues if issues are detected. They each tell something and in combination they also indicate something(s) that may need to be addressed. In my unfortunate experience (15+ years) the most where POs and Scrum people got is to build some of these numbers without understanding the underlying reasons (they lack technical competence mostly) and the result is a frozen fronline.

@ThePassionateProgrammer 2 ай бұрын

Time-to-value, the first metrics I discussed, is how long it takes to go from an idea for a feature to getting in the hands of our users. That, to me, is the most important metrics because it reflects the overall efficiency of development systems. Data can be misleading so I propose you keep it simple instead of trying to infer problems from the data. That usually doesn’t work very well. If you really want to deep dive into metrics used the right way then I suggest you dive into the work of Troy Magennis (www.focusedobjective.com/).

@saltybaguette7683 2 ай бұрын

Great video - subscribed! I'm a junior software engineer, I was wondering if you'd be able to answer some of my questions! - I feel a big challenge for all developers (but especially juniors) is rushing to development, instead of carefully laying out our goals, and roadmap to such goals. How do you go about planning software, and how do you balance planning and implementation? - On the same note: Do you use UML (a college professor's best friend) I'll be back with more questions when I have good ones ;) cheers

@ThePassionateProgrammer 2 ай бұрын

Hey saltybaguette7683, thank you for your great questions. Give me a couple of weeks and I’ll have a video for you that addresses them.

@ThePassionateProgrammer Ай бұрын

Hey Salty! I made a video for you on how I write code, what I do upfront, and what I do as I code. I realize these things that I’m sharing are advanced skills so don’t think you can instantly do these practices. It’s taken me years to refine. I think my approach, which I’m calling ‘backwards’ is a more powerful way of building resilient code. Let me know what you think. I haven’t addressed the UML question yet. Most devs don’t use more than class diagrams and maybe sequence diagrams. I try to think in code instead of artifacts. Code is what we want to end up with so it makes sense to go to code as quickly as possible. I use my unit tests to specify the behavior I want to create. That’s the subject of another video (series) that I leave for another day. Enjoy the video and thank you for the idea! It’s gonna be a banger (one of ten)-I can feel it! Here’s the link: How a Programmer with Over 40 Years Experience Writes Code Now - m.kzfaq.info/get/bejne/nc90oq1qm9vbdnk.html &list=PLVefSMWuVIvmQKpDlliEosmQHoG7EUbmC&si=VSW2MkryfqijBz8Y Happy coding! David