DevEx: What Drives Productivity
queue.acm.org
queue.acm.org
Also note that the prior work they repeatedly cite (no less than 5 times in as many paragraphs, and indirectly referenced several times in relation to the 20+ "sociotechnical factors"), i.e. reference number (9), is based on "semi-structured interviews with 21 developers". While a lot of the observations and recommendations are correct (and are obvious to any seasoned engineering manager), this seems like an academic exercise in picking three somewhat disparate aspects of development and trying to fit them into a geometric shape (an equilateral triangle) and then calling it a framework.
Maybe it is atonement of some sort.
Anyone claiming we need to invent our own metrics needs to read Reinertsen.
Though I disagree with Logan about the change failure rate (see https://two-wrongs.com/you-can-reliably-measure-change-failu...), I still think he is spot on in terms of MTTR.
Strongly seconding Reinertsen for anyone interested in this, though. I think this article of yours is particularly insightful and of high quality: https://lucasfcosta.com/2022/08/31/engineering-metrics.html
That says very little substantive about their results, though, so I'm curious how you think that matters to the discussion of developer productivity!
I feel like they are aware that not everything fits into the framework perfectly, but if your organization was trying to improve DevEx, this framework is a place to start.
Engineering leaders have long sought to improve
the productivity of their developers ...
What the rest of the article fails to discuss is how upstream-processes determine developer productivity far more than the three dimensions identified. To wit, the clarity and focus of "what and why" for an effort determines the "how and when." Which makes the answer to "knowing how to measure or even define developer productivity" no longer elusive, but instead quantifiable.
Few, if any, qualified developers I have worked with have a poor DevEx when the work needed to be done is well-defined (what) and can be explained such that a solution is identifiable (why). Solutions almost always flow from these (how), with an ability to communicate the work effort possible (when).
Skip the up-front investment by stakeholders on "what and why", "how" will remain nebulous, and "when" will be just a guess.
How would you quantify how much “what and why” has been defined? Some kind of diff between the planned architecture or requirements on day 0 and the final codebase?
Has been defined or needs to be? I'll assume the latter for sake of discussion.
When skeletal feature specifications can be coded against requirements such that stakeholders and engineers can have a meaningful discussion of the functional expectations (as captured by the specs), along with the engineers having enough understanding to perform impact analysis on the existing system (if any). This is usually an iterative process engaged before any significant implementation is undertaken.
Essentially, the upstream-processes I reference regard establishing a shared understanding. As such, most delivery metrics are not relevant at this point. However, an important benefit is that unneeded effort is often identified and not engaged.
> Some kind of diff between the planned architecture or requirements on day 0 and the final codebase?
In general, system architecture and code bases exist in the "how", not in the "what and why." At a macro (business) level, sometimes architecture decisions such as whether or not to use a cloud provider or data centers do influence the "what."
It's kind of like branching in a programming language. Typically, the earlier an execution flow is determined, the less are needed later. So, too, the sooner stakeholders clearly define "what and why", the less effort is needed to identify "how."
I know this is captious of me, but I never understood this phrase "lived experience". As opposed to..? Is there another kind of experience?
> The developer's team, role and responsibilities, and seniority all impact their lived experience.
Why not just "all impact their experience"?
I’m not the author, but I found that to be a highly important distinction for them to call out. It is about the way that each individual developer feels during each individual day, in a way that is hard to capture with statistics and summaries and lists of technologies and descriptions of processes.
I have heard of someone describing their “lived experience” of discrimination. They perceived discrimination in many situations where they had no evidence that the other party wasn’t impartial. But often the implication is that “lived experience” represents some form of truth that cannot be questioned.
Lived experience is when you encounter something and you live through that experience.
Learned experience is when you read about an encounter someone else lived through and they explain condensed points of emphasis.
The social media plugin and reporting system for the SaaS I'm working on is an idiotic, over-engineered monstrosity. But, after trial and error, I've mastered it from a what-goes-where-standpoint.
If I were to document the entire thing from my vantage point, it'd take me a week, and even if I did it, it'd take another dev about a week just to wrap their head around it to implement a new feature AFTER reading what I wrote. Or, I could do it between standup and lunch provided I had no distractions.
I as an outsider may observe friction in a developer--customer meeting. Ask the developer, and they may reveal that they found the arguments during the meeting highly valuable and productive. A lot of case studies and experiments in productivity improvement are observational. You do something and then you look at the results, rather than how the lives of the people involved changed.
When an outsider looks at a situation, they often see something very different to what the people in it did. That's the difference between lived ("insider") and observed ("outsider").
(Of course, strictly speaking, you don't get lived experience from interviewing people. People being interviewed tell you, to some extent, what they think you want to hear at that time. To really get closer to lived experience the researcher has to embed with the group being studied and work with them for some time.)
Not being able to get color scheme misalignment fixed with multiple team-years’ of effort is shocking and appalling.
Most human organisations are crippled by pathologies mistrust and misaligned incentives.
Fixing those almost always involves ending the org and building a new one.
Question: how do we get people to do more work for us?
Answer: try controlling factors under your control that your employees will gladly tell you about if you listen
Would it be possible to also include data on value of software created? Maybe use historical sales data to map development effort to revenue? Maybe there’s situations where developer experience is optimal (lots of freedom, no meetings, personal project budgets) but limited commercially useful work gets done.
Very solid groundwork for analyzing your development.
Welfare states reduce that level, this subsidising businesses (!) but at some point you gotta pay if you want more than the basics. It's not extrinsic motivation - it's much more a hygiene factor to allow intrinsic motivation to come tomplay
I'm very suspicious of survey grounded research. p-values in the social sciences are high for a reason.
All these books/frameworks are all the same.
Accelerate: "Copy what successful teams do and your team will suddenly be successful"
The Phoenix Project: "IT department was bad, they made small changes and then eventually they all lived happily ever after"