Software Development Metrics: What are Process Metrics in Software Engineering
Most teams don't know what or how to measure. You're not alone.
After advising hundreds of CTOs - I noticed a set of questions that consistently came up. They seem simple at face value but in reality they are some of the hardest questions to answer as an engineering leader.
Common Questions:
- Are we getting better?
- Where can we improve?
- Are we even good at all?
As a manager it can be incredibly frustrating to not have the answers to these questions - even more so when you have to answer to outside stakeholders.
We often rely on trust and culture - but even in the best cases these questions largely go unanswered. It's incredibly difficult to quantify a team's progress and many go so far as to say "it's impossible" and "wrong to even try".
The end result?
"We're flying blind. And we know it."
Software Metrics are incredibly hard.
The history of software development metrics has shown many (flawed) attempts at measuring developer productivity. Half baked metrics can ruin teams, destroy culture and make developers live miserable. We've seen it time and time again from lines of code to coding days per week - failed after failed attempt.
Common Metrics That Fail - Output Metrics
- Commits
- Lines of Code
- Pull Request Count
- Velocity Points
- "Impact"
Output Cannot Be Measured Accurately
These metrics fail because they attempt to measure output - but software development isn't a factory assembly line where we can count up the number of widgets produced and quickly determine how much they cost.
Software Development is more like art
Throwing more paint on the canvas is often more harmful than helpful. More lines of code or commits is often the opposite of what we want and just as it may take an artist a full day to find out the perfect brush stroke - a single line of code can take an immense amount of effort to get right.
"There are many things we can measure but very few things we should."
So what should we measure?
To answer that, we need to think about why we're measuring at all. Most of us simply want to drive improvement and express our efforts in a tangible way.
Ultimately what we want is a productive, happy team. But what does developer productivity look like? What do you imagine when you think of a productive team?
Are you imagining a lot of lines written? A ton of pull requests created? What about a super high velocity count? Probably not. You're probably imagining a team that's responsive to one another, collaborating effectively, and has a really efficient process - and the metrics you use should reflect that.
Measure what matters - Process Metrics
Use software development metrics that enable productivity.
Measuring responsiveness, collaboration, and process allows the team to improve how they work together. What's great about process metrics is - as developers - we really care about this stuff. They directly impact our day to day and allow us to improve while having concrete numbers to show our organization.
When we measure process we drive productivity - ultimately giving leaders quantitative ways to express improvement while enabling developers to drive meaningful change in their day-to-day experience.
"Process metrics enhance culture. Not hurt it."
What are process metrics?
Download our Book of Engineering for a full list of process metrics and how you can use them on your team.
You can also subscribe to our newsletter or reach out to us directly at julian@usehaystack.io. We'd be happy to help you design what metrics are best for your team.
Haystack helps engineering leaders identify blockers and trends. Instead of guessing if you're improving, or constantly bothering your team for progress updates, simply use Haystack to get alerts in your inbox every morning. Plus a dashboard to track improvements over time.
.png)
.svg){kind=small}
.svg){kind=small}
