The intersection of Security and Developer Productivity
Reassessing Misconceptions of Cybersecurity in Productivity Metrics
Cybersecurity is top of mind for many organizations and given recent high-profile incidents (example Uber), many organizations are starting to rollout various cybersecurity initiatives within their organization.
This will no doubt have an impact on developers and specifically their productivity, but the question is - how (and maybe more importantly why)?
Reviewing metrics alignment
By looking at the metric we have reviewed previously, DORA and SPACE, we see that we have 4 metrics for developer productivity from DORA, and 5 types of metrics across 3 levels with SPACE (outlined in this article here).
Of these metrics, some will be positively impacted and others negatively for any new cybersecurity initiative related to DevOps (or DevSecOps depending on your preference).
Below let's discuss why I grouped them in this manner.
Negatively Impacted
Lead time for changes - this metric would punish developers as they would be perceived to be less efficient.
Deployment frequency - it would be impacted initially when these tools are deployed because there are lots of false negatives and it takes time for the team to adjust. Once the team got used to the processes frequency would increase.
Developer satisfaction - cybersecurity rollout typically impedes flow, I've found most developers dislike these tools to begin with. Once they realize the benefits and the fact it causes less work, they often change perspectives.
Perception of code reviews, story points shipped, # story points completed, coding time, code review score, PR merge times - initially negative because of the number of false positives translates to a significant reduction in flow.
Lines of code - the tools to measure this metric will highlight risks of unnecessary code, and as such reduce the amount of code created. For the organization this is a net positive as security risks are reduced, but developers metrics would skew to say fewer lines of code were produced; it's not a great metric to measure in the first place.
Productivity perception, flow through the system, handoffs, lack of interruptions - these will be negatively impacted as it changes in development processes means it will take longer when such tools are rolled out.
Not Impacted
Quality of meetings, discoverability - minimal impact for cybersecurity rollout.
Positively Impacted
Mean time to restore - incident management plan created as a byproduct will mean should an issue arise, business recovers quickly. As such this metric will improve.
Change failure rate - This metric value will go down once the team acclimates to the new processes. An additional benefit related to this metric would be the fact that the entire team would be less likely to be involved in issues.
Satisfaction with code reviews, satisfaction with engineering system - benefits for developers and teams are issues are resolved earlier and in less stressful scenarios, rather than having to deal with hot fixes in time crunch they're able to handle at a more measurable pace.
Code review velocity, acceptance rate, reviews completed, review timing, knowledge sharing - since it gets integrated earlier into the process, the speed for these metrics should increase relatively quickly.
Customer satisfaction, reliability (uptime), # commits - these should increase as more issues are found in the earlier phases of development lifecycle prior to getting in front of clients.
Another way to look at it is developer opinions on these rollouts will be dependent on the metrics selected. If they feel the metrics hold them accountable for changes outside of their control, they will look at cybersecurity negatively and it will impact how it rolls out to the organization.
Should they be made aware of the upcoming changes, and how the metrics measured will accommodate or even change to give them positive feedback, you're likely to have a much better experience.
For this article, I've just focused on the previous developer productivity metrics we discussed. There are other metrics that could be integrated such as code coverage, vulnerabilities identified and resolved, mean time to detect/respond to name a few. They are, however, security specific metrics and not necessarily related to productivity - arguable many productivity metrics include some component of these.
The point I want to finish here with is understand which metrics to select and the impacts to your teams; these aren't written in stone and should be changed so team morale isn't negatively impacted.
How have your developers (or you as a developer) been impacted by cybersecurity initiatives?
We have a favor to ask of you. If you have been reading this newsletter and have found the information of value, please use the link below to share our newsletter. The more readers we have, the better we can learn and serve you. Thank you.