The past few months have been quite unproductive for me in terms of work, side projects, etc. If it's because of social media distracting me, lack of good sleep or just the feeling of laziness, I can't really pinpoint the cause. I tried the Pomodoro Technique, avoiding social media, avoiding distractions but these were all short lived. This got me thinking what could actually be the cause and what I can do to help. So I started researching a bit about productivity and how I can measure my developer productivity specifically.
What is Developer Productivity?
Traditionally, developer productivity would be defined by how efficiently and effectively a developer could deliver given tasks within a given time. While this isn't wrong, I find it incomplete. It seems to be focusing mainly on the activity of the developer and skipping out on other aspects like their satisfaction, quality, etc. Let's look further into this.
Conventional Measures
Not so long ago (might be used still), these were some of the metrics to identify developer productivity:
- Lines of code written
- Number of bugs fixed
- Number of hours worked
- Number of commits
While these are easy to measure and indicate some level of productivity, it definitely cannot be taken at face value to decide whether a developer is productive or not. There's many other factors that play a role. For example, personally, I cannot focus or work well if I've not gotten at least 6-7 hours of sleep the previous night.
Developer productivity is not just about activity or individual performance. We need better measures that are not only focusing on the technical activities of a developer's daily life but also the wellbeing/psychological side of it.
Enter, the SPACE Framework
Source: Youtube
A group of individuals from Microsoft Research, Github and University of Victoria came together to identify metrics that can measure developer productivity with a holistic approach and not just based on developer activity alone. They divided the measures into 5 dimensions abbreviated as SPACE as shown above. Each of the dimension has been explained briefly to give you a sense of the framework and how it can be used to measure developer productivity.
Satisfaction and well-being
Satisfaction refers to how fulfilled developers feel with their work, team, culture or tools. Well-being, on the other hand, refers to how healthy and happy they are. Research states that productivity and satisfaction are correlated and that satisfaction can be one of the major indicators of productivity.
Metrics
- Developer Satisfaction - Qualitative metric related to how satisfied developers feel at their work. Data can be gathered through surveys or questionnaires
- Developer Efficacy - How confidently and efficiently can work be done
- Burnouts - The amount of stress taken by developers due to extensive workloads or other factors
Performance
Performance measures the outcome of a process or a desired goal. It is not to be mistaken with output. A developer can write thousand lines of code (output) but this does not necessarily mean that it is of high quality (outcome). Alternatively, the code might be of high quality but it might not be of any value to the customers. We must look at the goal that we were trying to achieve and compare it with the actual outcome.
Metrics
- Quality - Number of bugs, vulnerabilities, uptime
- Impact - Usage of the implemented features, customer satisfaction, cost reduction
Activity
As mentioned above, the most commonly used dimension for measuring productivity. Simply put, it's the developer's activity. It's the number of actions or outputs in the course of performing a task. It is worth noting that the activity we're discussing here is not limited to coding tasks. Developers are involved in many other activities such as reviews, mentorship, documentation, etc. These are all to be considered to get a complete sense of their day-to-day activities.
Metrics
- Design and coding - Number of commits, pull requests, documents contributed
- CI/CD operations - Deployment frequency
- Operational Activity - Incident mitigation, bug discovery
Communication and Collaboration
This focuses more on teams rather than individuals. It's how easily developers and teams can communicate and work together. It also aims to measure the flow of information. Especially for bigger teams, where there are multiple point of contacts and a large knowledge base, it becomes crucial to make sure that developers find it easy to find the piece of information they're looking for quickly.
Additionally, it can also be helpful to measure the quality of the reviews being done, the frequency of 1 on 1's being carried out and number of meetings in general.
Metrics
- Onboarding Time - Time taken to onboard new developers
- Information Discovery - Ease of finding documentations or getting help
- Integrating Work - Teams being able to connect and communicate easily and quickly
- Networking - Seeing who is connected to whom and in what way
Efficiency and Flow
How well developers and teams can make progress on their work or complete it without interruption or delays. Sometimes we get into this state called Flow where we feel like we're 'in the zone' and highly productive. This dimension tries to measure that. It's how well a developer can get a piece of work done while being efficient and feeling good about the work that they're doing. There are different ways in which one can get into this state, it differs from person to person. Example, one might block off a certain time as their focus period. The other might use apps to track the time they have been productive and improve on it.
Metrics
- Number of Handoffs - Handoffs across teams
- Flow State Frequency - Number of times you can be in flow state and complete work
- Number of Interruptions - Ad-hoc meetings, increased context switching
- Time Measures - Wait/feedback times. For example, the time from when a PR is opened to the time a feedback has been received
Using the framework
To measure developer productivity, you can pick the metrics from different dimensions and measure against those. It is recommended that you pick metrics across at least 3 dimensions to get a better result. The second recommendation is that at least 1 metric must be based on perceptual measure like asking an individual how they felt about the day.
The metrics should be balanced between each of the dimension to avoid skewed results. I believe an individual must pick the metrics that he/she feels can help them give good results when it comes to measuring their productivity. If they're uncertain, they can always start with a smaller set and then add metrics to improve the measurements. Having too many metrics can also lead to confusions and decreased motivation.
In my opinion, using Activity metrics extensively must be avoided because they can lead to incorrect results. For example, using Story Points as a metric can lead to developers only working to complete and pick up more story points while giving up on other aspects like helping out teammates, producing high quality work, etc.
The SPACE Framework can be used by individuals, teams or systems. In this article, I have focused on it's applications for an individual developer. Keeping that in mind, these measurements should ideally be used by individual developers as a method of self reflection rather than for organizational needs like OKRs or performance reviews. This ensures that the developers are not biased towards the data they enter.
Conclusion
To conclude, I believe the SPACE framework lays out a good set of principles to measure our developer productivity using a holistic approach and not a conventional one. I am looking forward to see what results I get out of tracking my productivity using the framework and how I can improve.