"The BEST Developer Productivity Metrics We Have... SO FAR"

Подписаться 202 тыс.

Просмотров 14 тыс.

50% 1

Are DORA metrics the best measure of developer productivity we currently have in software engineering? Martin Fowler and Dave Farley discuss software developer productivity including the 4 KEY metrics used to marry the technical aspects of software development to those of business management.
This is a clip taken from Martin's FULL engineering room episode, that you can listen to HERE ➡️ open.spotify.com/episode/3xcE...
-
🗣️ 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 #developerproductivity

Наука

Опубликовано:

23 мар 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 27

@username7763 2 месяца назад

Lets just borrow from the mechanical, electrical, and civil engineering productivity metrics. Oh, that's right, they don't do that because it would be dumb and counterproductive. No one measures how productive, productivity metrics actually is. There is always something at the top of metrics that is not measured. The people pushing metrics like to be at that level. Measure others, but not myself. Are the measurement folks actually productive? Nope!

@Starshine777 2 месяца назад

"allows users to get their job done better" I just wrote that on a job application that's the whole point of a software

@Starshine777 2 месяца назад

Let's get Nicole on here

@ichduersiees8374 2 месяца назад

The first 2 minutes of the talk are invaluable for any tech leader having to discuss with business about the lack of dev productivity measures. Unfortunately DORA is often not accepted by business as it measures very technical things. The positive business correlation is not so obvious (e.g. number of releases. Compare this with to the number of leads generated by the marketing organization). In doubt they are even afraid of more releases and for sure they don't understand the advantage from releasing every couple of days vs releasing every couple of hours.

@ContinuousDelivery 2 месяца назад

I think it depends on how you frame it, what the DORA metrics actually measure is the quality of the software that we produce, (Stability) and the rate at which we can produce software of that quality. These are clearly business relevant metrics, and they are generic, and they PREDICT organisational success, including things like making more money, which is DEFINITELY business relevant.

@someverycool4552 2 месяца назад

@@ContinuousDelivery The issue with DORA metrics is that it doesn't allow the companies to measure our productivity as individuals, so what are they going to do about performance reviews? In general though, in an ideal state, all the DORA metrics should be as optimal as possible. Deployments, getting code to "live", all of it should be near instantaneous, in many cases there's no reason not to be. I'm not sure if it actually is correlating the correct thing though. If engineering is setup correctly from the scratch, DORA metrics should be near perfect. If they are not, it is unclear to me whether a company having issues with that would be able to improve that in the first place.

@Starshine777 2 месяца назад

3:51 I have a music background but I like software development good software companies employ people who intuitively understand the connection between the programs and the people and the purpose those people are going to beat the metrics for decades to come yet. they'll stay ahead because they'll be faster than the metrics to catch on to what's wrong. we just don't employ these people in the industry enough

@nickbarton3191 2 месяца назад

Measuring outcomes is only helpful if the whole business takes responsibility for them. Otherwise, it just becomes a blame game between departments.

@PaulSebastianM 2 месяца назад

2:47 did he say it's kosher? Isn't that related to food? Confused 😕.

@JohnDoe-bu3qp 2 месяца назад

It's also an expression meaning everything looked good, looked ok, "passed the smell test".

@YisraelDovL 2 месяца назад

"Kosher" literally translates to "Fit", in food it would mean "Fit for consumption"

@brownhorsesoftware3605 2 месяца назад

Programs are one or more plot lines. Data is organization. Code is focus and plot. Software exists in time like music - it is serial. Speaking for myself, being an English lit major who is wicked good at math and music from a family of engineers is an excellent background for a software engineer. 😉

@johntrevithick5900 2 месяца назад

Individual developer measurement is probably impossible, given the specialisation needed within a team. Was it Bob Martin who (first) said that a team should be the basic unit of development, not the individual developer? Or was it one of you guys? :)

@ContinuousDelivery 2 месяца назад

I don't know who said it first, but I am pretty sure that Bob, Martin and the Team Topologies guys would all agree with me that the Team is the unit of productivity in software.

@geffhome 2 месяца назад

Did I miss it? What were the four metrics?

@YisraelDovL 2 месяца назад

Was looking for them as well

@Mark73 2 месяца назад

You expect a question on a thumbnail to actually be answered in the video? Are you new to RU-vid?

@passerbyp8531 2 месяца назад

Security kills productivity. However, I never found out how to fix it. Any ideas?

@username7763 2 месяца назад

I think it is wrong to view it in terms of productivity. Security makes the problem much harder and thus takes longer. Productivity hasn't changed, the problem being solved has changed. "Non-functional" requirements have a huge impact on the difficulty of problems. Yeah productivity metrics will get thrown off by things like this, but no one should be using them in the first place.

@passerbyp8531 2 месяца назад

@@username7763 I don’t agree about degradation of productivity when security requirements needs to be addressed. Productivity degradation must be addressed when security requirements will be implemented and not forgotten and addressed afterwards.

@username7763 2 месяца назад

@@passerbyp8531 Take a project with 1 engineer who is pretty good. He/she has some baseline level of productivity. Add a security requirement to it. It will take longer to get done. Did you change the person or the person's skills? No, you changed the goals of the project. This is increasing the project scope and not decreasing productivity. The task at hand is harder, the team isn't less skilled.

@thebigsteiny 2 месяца назад

You need to measure it against a baseline, being when a security flaw exposes all your clients confidential information, the reputational cost, the cost to repair it, the endless meetings about it involving people who have no idea about security etc. Once you have that cost baseline, then compare to implementing security measures in your code and see if you're 'less productive'?

@passerbyp8531 2 месяца назад

@@thebigsteinySecurity always has highest priority compare with productivity. So, it’s up to security protection how to make productivity higher or lower and indeed in most cases it make it lower and didn’t saw on my life when security protection increase productivity.