What is developer productivity? Is there an inevitable trade-off between speed and quality? How can organisations foster long-term productivity gains to drive better business outcomes?
These were just some of the questions that Codurance Co-founder, Sandro Mancuso and CodeScene Founder, Adam Tornhill discussed at the Codurance Fireside Chat #63.
In this article we recap on the key learnings from the conversation and signpost resources for you to continue your learning and get started.
The first question to answer as a baseline is the meaning of software developer productivity. Sandro and Adam described it as how well the software organisation supports the business; usually this includes speed of feature releases, but it's more - the speed has to be sustainable, shipping month after month with little surprises. This predictability leads to confidence and achieving delivery deadlines; key for successful businesses.
The optimisation level of developer productivity can also be impacted by alignment between the business and software teams. If there is a misunderstanding of expectations and what can be achieved with a timeframe, more waste is found which can lead to productivity issues.
However the number one killer of IT projects and thus having an enormous impact on software developer productivity is unplanned work. Adam describes this as everything that we don’t want to do and didn’t plan to do such as defects and production crashes. To improve productivity, it is critical to come back, shift the focus and to focus on fixing production issues.
Mature product developer productivity can also be characterised by organisations that connect their code quality to business outcomes. In his research study Code red: the business impact of code quality, and using quantitative data, Adam found that businesses with good code quality ship twice as fast and have 15 times fewer defects compared to those with poor code quality. With this data to hand, it becomes easier for business stakeholders to visualise where the good and problematic parts of the software exist and they can have better conversations about trade-offs.
There is also an assumption by some in the industry that if we want to go fast, we should accept some drop in quality; that a drop in quality is an unavoidable but necessary evil of getting features into production and products into the hands of customers as fast as possible. Through the work of Sandro, Adam and many others that focus on quality and Software Craftsmanship, there is no such trade-off - and Adam’s research has the data to back this up. Once rework and bugs are measured alongside releases in units of work and when outcomes are measured rather than processes, the data shows that the opposite of the quality compromise is true - if we want to go fast, we in fact actually need to go well - developers will be quicker if they have good quality code, there is no trade-off after all.
Gaining buy-in from the business to invest in code quality to drive developer productivity can further be achieved through introducing test automation to ship faster and removing waste by correlating changes in code and architecture with efficiency improvements.
Another killer of software developer productivity is technical debt. Whilst a lot of tech debt may not be blocking the business from releasing features, it can be an enormous drain on developer time; on average developers spend most of their time in only between 2-4% of the codebase. If some of this codebase is not critical to business continuity and growth, keeping some technical debt and repurposing developers towards other productive work could be sensible. However, if developers are working on an area of the codebase that is touched often, they must ensure the code is as clean and simple as it can be. If there are too many developers working on the same code, this could lead to ‘developer congestion’ and increase defect rates (code smell issue).
A way for organisations to measure the productivity of their software development team can be using the DORA 4 key metrics of deployment frequency, lead time for changes, change failure rate, time to restore service (we discuss this more fully in this blog by Matt Belcher). Mature organisations with a distributed architecture for example would allow developers to release multiple times per day, usually a sign of highly productive development teams. However for this to be achieved successfully, there must be good alignment of requirements across the business and multiple teams with automation of processes built in to go fast and go well.
This leads nicely to consider team behaviours - to optimise software developer productivity, there needs to be strong alignment with architecture teams and with the business. Operational team boundaries should be narrow and should include neighbouring systems to allow for synergies and avoid knowledge loss.
Whilst fastidiously focusing on quality is a desire for any organisation that wants to deliver well for the business, there is usually a balance between excellence and pragmatism (as the Software Craftsmanship manifesto expresses). Excellence cannot be unbounded; it is important to look at the constraints in place and do the best job possible. Delivering features into production is a must so instead of stopping, productive developers clean the technical debt as they go along.
With Sandro and Adam’s hour nearly up, they summarised their key takeaways to achieve software developer productivity as:
- Create a culture of continuous improvement and good communication.
- Ship fast and use data and metrics to drive improvements.
- Use data to demonstrate the quality of your architecture and code to make changes and demonstrate the impact of good or bad code to the business.
- Look at the entire value stream to get good quality software into production.
- Everyone owns quality and is responsible for driving developer productivity - the business, the developers, the testers - everyone is part of the solution.
Sandro Mancuso is the co-founder of Codurance. Book a demo of our Software Quality Assessment - a solution that assesses the quality of your software to make confident decisions, evaluate progress, and optimise your systems and organisation with insights backed by empirical data.
Adam Tornhill is the founder of CodeScene, a code analysis and visualisation tool to help measure and improve code quality, team dynamics, and delivery.
Watch the full recording of Sandro and Adam’s Fireside Chat #63 on YouTube or listen to the Podcast.
Want to learn more about Software Developer Productivity? Read more here.
