What is ‘Developer Productivity’?
Providing a mental model that informs developers where to focus their time and energy to improve productivity
⚠️ The definition of developer productivity is wide ranging, but some definitions are dangerous and outright harmful.
✅ Developer productivity is best when the creative process and analytical mind are allowed to coexist and mingle.
Developer Productivity != Assembly Line Productivity
There is an important distinction between developer productivity and assembly line productivity. It’s natural to pull from research in things like car manufacturing to form mental models about how software engineering should work. This can be useful at times, especially when considering the testing and release process, but can become quite counter productive when considering the R&D side of software engineering. Because of this, developer productivity ends up boiling down into two divergent mental models:
We create, we build (knowledge worker productivity model) ←THIS ONE! USE THIS ONE!!!
or..
They think, we do (assembly line worker productivity model)
We create, we build
Developer Productivity is juiced up through maximizing human attention on solving problems creatively while letting the computers do things that can be automated.
When considering much of the literature on DevOps, especially the sections focused on CI/CD, it can be easy to fall into the trap of adopting the assembly line mode of thinking. Once peer review is complete and code has been merged to trunk, the process from there should absolutely resemble an assembly line.
The problem is that DevOps literature, especially Accelerate, DevOps Handbook, and the DORA metrics, are laser focused on the right side of the image above. This is not to say that these metrics aren’t useful or relevant, just that they are only part of the ‘developer productivity’ story.
Quote from DevOps Handbook and Accelerate that back up what I’m saying:
“For the remainder of this book, our attention will be on deployment lead time, a subset of the value stream described above” — The DevOps Handbook
“There are two parts to lead time: the time it takes to design and validate a product or feature, and the time to deliver the feature to customer.…We measure delivery lead time as the time it takes to go from code committed to code successfully running in production.” — Accelerate
The other part of the Developer Productivity story is creative problem solving. If you crack open Accelerate and check out Appendix A, you’ll find ‘Capabilities to drive improvement’. In other words, the assembly line metrics (ie DORA metrics) that are often used to measure developer productivity are impacted by team capabilities. Some of the capabilities include:
Product & Process Capabilities
- Gathering and implementing customer feedback
- Making the flow of work visible
- Limiting batch size (ie, story size)
- Fostering and enabling team experimentation
Lean Mangement Capabilities
- Limiting the amount of work in process (WIP)
- Having a lightweight change approval process
Cultural Capabilities
- Encouraging and supporting learning
- Supporting and facilitating collaboration
- Providing resources and tools that make work meaningful
Architecture Capabilities
- Designing for loosely coupled architectures
- Architecting for empowered teams
Technical Capabilities
- Test automation
- Continuous testing
- Code maintainability
If you want to improve productivity, you need to focus on improving capabilities, not the DORA metrics. In other words, the DORA metrics are the result, not the target.
They think, we do: Demoralization included!
Thinking of software engineers as factory line workers is demoralizing and self-defeating. Measuring software delivery like a factory works. Measuring software creation like a factory would be like measuring an artist’s output based on number of paintings produced.
If only Van Gough had assembly line metrics to guide his art!
The underlying assumption with a factory assembly line model is that each ‘piece’ of work is comparable (or better yet, exactly the same). To manage assembly line work, the goal is to limit variance. Each job role in the assembly line should be well defined to ensure interoperability of the labor force.
When you overlay this method of managing work on an innately creative process (in software development, each piece of work is by its very nature unique), it causes problems. Instead of developers using their creative efforts to push the envelope on what is feasible from an engineering standpoint, they are instead encouraged to stay within the predefined ‘box’ that others have imposed on them. In other words, it reduces innovation and continuous learning. It also results in estimates driving delivery expectations. Predicting when something that has never been done… will be done… is really an educated guess. Using these guesses in a complex system to drive scope estimates within an organization results in… undesirable effects.
How to think about developer productivity
Rapid feedback loops turbo charge learning and problem solving
Developers should be getting feedback on their work multiple times a day. Whether it is feedback from their IDE or peer review, this feedback is the way developers improve their own personal capabilities to solve problems. The team should always be looking for ways to optimize their feedback loops.
Goldilocks zone of cognitive load
Human attention is a scarce resource. The areas we should be placing our attention should be the highest value arenas. Unnecessary complexity is the enemy of productivity. Reducing unnecessary complexity of things within your control will allow focus on more important problems. ‘Paper cut’ problems, when added up, reduce developer effectiveness. Take time to eliminate paper cut problems.
Optimal conditions for ‘Flow’
Achieving a state of ‘flow’ is something that can be engineered. When making calendar trade-offs, make sure flow time is prioritized. It is possible to enter a state of flow as a group in ensemble programming, so this doesn’t necessarily mean having blocked off ‘collaboration-free’ time.
Product Ownership over Product Owners
Building something that is desirable, viable, and valuable is everyone’s responsibility. Don’t outsource it to product management and designers. Developers should own the work they do and make sure they understand the problem their work is solving. If they don’t, they will probably be building something that doesn’t meet the original intent.
Some tactics that just seem to work
- Limit work in progress by only planning what you can actually accomplish in a given period of time (the period should be a month or less) Your WIP Says it All
- Build in ‘golden hours’ of collaboration as a team: How to Run a Ritual Reset with Examples | Atlassian
- Reduce complexity by understanding how you’ll test for success before beginning to code (Test driven development and/or behavior driven development) TDD: Test-Driven Development — XP123 — TDD
- Use paired programming or mob programming methodologies to learn and teach simultaneously: On Pair Programming
Summing up
Successful technology delivery is difficult. Rather than setting up measures and target conditions, focus on the experience developers are having. Use these signals to focus capability improvement efforts.
