One thing that’s been in the news recently is ‘developer productivity.’ There was an interesting article that McKinsey brought out on a framework for measuring developer productivity. We are not going to comment on that. It is what it is.
Dan North, who we know and respect, is a brilliant technical leader and a fantastic speaker and writer. We have followed him for years. He’s clever, super bright, and a nice guy as well. He wrote an assessment of the McKinsey article. It is a polite, fair, and even-handed assessment. And it’s a good read.
We find it surprising that ‘developer productivity’ has never gone away. You heard people talking about this in the 80s and the idea of paying developers by lines of code. And it was even rubbished in the 80s as a foolish thing to do. There’s a famous story about developers removing bad code from the code base and having negative numbers by the end of the week and then asking if they have to pay the company back money. It’s never been a good idea. It strikes me as strange that in 2023, we are having the same discussion.
We aren’t stacking boxes
Our first reaction when I read both articles was that it felt like something from the 80s. When you think about it, in terms of the Cynefin framework with chaotic, chaos, complex, and known, when something is known and predictable, like stacking boxes, you can predict how long it’ll take to do something. And what you would expect to see. In terms of how modern software development works, it’s very different. There’s a tremendous amount of thought work required to ensure you’re doing things the right way.
If only a company were willing to help you write code, like Thoughtworks! Some developers think they get paid to write code, so they write code all day. We talk about the fact that it is different from what the job is. We’re software engineers, not developers because you’re solving problems. If you’re paid just to write code, it is easy to automate and replace that. It’s different from where your value is.
Of course, you often write code to solve something, and that’s an essential part of the job, but it’s not all the job. It goes back to splitting things by function and socio-technical. If you have different functions, there’s going to be a disjoint between them.
Turning up the heat in the ‘developer factory’
In his article, Dan identifies several weaknesses and factual errors. It’s worth reading both Dan and McKinsey’s articles. What gets me is that McKinsey is an intelligent company that sees a massive demand for this because many companies are asking this question. And it’s worrying because some large companies want to turn up the heat in the factory of developers. And get them to write more code!
It points towards the criticality of software and the fact that most businesses will become software companies over time. Software becomes a critical part of the value chain and how it delivers outcomes and value to users and customers. They need to know how to do that and get the most benefit from their tech investment. Developers become a big call center for some organizations, but you want to measure something other than that way. You want to measure the impact and the outcomes of your teams. Are they solving your business problems and meeting the needs of your users?
Companies could use that sort of framework and evaluate developer proficiency based on the number of lines of code. Our ability to perform in such an organization should be about the outcomes and the problems we are trying to solve. How are we approaching those problems by beginning to iterate and experiment? Good results, for the most part, only sometimes involve code.
Slow is smooth and smooth is fast
It is ‘Code is a liability’ because capabilities evolve to the point that you don’t need to build them. Imagine sitting in one of these organizations, and somebody says, “We need a document management system.” There are two paths. You can figure out your document management system and start building it. Path 2 is ‘Let’s use S3!’. But would you get a massive bonus for saying let’s use S3, and some other team does the integration? I am still determining where that would stack up with developer productivity. But it’s highly productive not to build it.
The scenarios that stress me out are when there isn’t a clear picture of the problem or the priorities and I am confronted with reams of code bases. And I’m using the code bases to work out what’s going on to correct the situation. And there must be more time for a successful or good business outcome. They have focused on the workspace and writing code. It goes back to our mantra: Slow is smooth, and smooth is fast. Take your time. What’s your business problem, business architecture, and technical architecture? And what’s the most sensible approach for the deliverable?
Code commits going through the roof?
You don’t want to beautifully engineer with developer metrics and productivity for a problem you don’t have. Your developer productivity metrics are fantastic, but you need to deliver critical business outcomes or impact because you need to think about your clarity of purpose upfront. And you still need to think about your users, their needs, and key indicators of progress.
Let us pose a question. You’re in an org, working the way you would, focused on business outcomes, and measuring your success correctly, and suddenly, your code commits go through the roof. What does it indicate? It indicates that there’s a severe problem. If your most experienced engineer’s code commits go through the roof or elevate abnormally, there’s something weird going on.
You need your best engineers, your best thinkers thinking upfront and not typing for the most part. You need your best developers or those who can think about the problem and help the team address that problem with the least amount of code.
AI Dev Tools and Developer Productivity
There’s a segue into AI Dev Tools. If you measure developer productivity, can CoPilot, CodeWhisperer, or ChatGPT help? There are interesting use cases. A decent AI system will augment what you do and not replace what you do. And it’s no different for software engineers. How do I write a function in node which makes it a different color, and it’ll generate a piece of code? Or here’s a piece of code in Rust; tell me what this does. That won’t help with a legacy code base with tens of thousands of lines because it’s probably all spaghetti! The dev tools are interesting as an accelerator if you have to poke at something or troubleshoot and you need a quick prompt.
There are productivity gains. If you want to write in a new language, the AI co-pilots can guide and help you learn. But that may not be your critical path for delivering business outcomes. If you over-focus on some of this stuff, then you need to optimize the right part of your value chain.
Making bad developers worse
I don’t want to be alarmist, but it would make good developers better and bad developers worse if you were measuring developer productivity by the lines of code. If you’re shipping code that you still need to write, and you need to know how it’s hanging together faced, there’s a lot of risk involved. Strong engineers will use AI Dev Tools to experiment and learn or to verify or check something. But they will take ownership and responsibility for whatever it is they’re delivering on the back of it.
It’s back to the old DDD and testing scenarios. What are you trying to develop code for? And what tests are you trying to pass, and what business behavior are you implementing? What KPI are you influencing? And what users and needs are you delivering these behaviors and capabilities for? Let them generate the code quickly. If it frees you up to think about the fundamental things, it’s a net positive.
No magic tool or developer productivity technique
It’s the hard part. Ask your team: ‘What’s your business KPI?’. It’s essential that the team knows and they’re clear on what they need to build, understand when they have built it, and they can measure how well it’s been built. But if a team replies: ‘I don’t know, I need to think about that or talk to someone,’ it is going to be difficult. Because if the team can’t think of a KPI for what they’re building, they’ve just been asked to build something, and they need to know why.
It leads back to the Northstar and having clarity of purpose. It takes work to put that into developing productivity. Because you need to be joined up, when a piece of work gets to the team, if there’s clarity and the team knows how to talk and find out what it is, they can solve the problem. A thorough understanding of the problem does not have a magic tool or developer productivity technique.
Developer productivity is an ebb and flow
Once you have clarity of purpose, you can map the value chain and components to see the inertia barriers to rapid product delivery. Coding may be fine. Your release process or cloud infrastructure could be the problem. Any number of things could be barriers to actual developer productivity. Writing code may be OK. You should address other items in your ecosystem.
It may even be a function that is outside engineering! Slow is smooth, and smooth is fast, which is exciting and understanding how you do certain things—slowing down to probe things with the Northstar or think about your design. They’re all beneficial things to do. By identifying inertia barriers, your execution can go fast. There’s a shape of productivity that is not rapidly decreasing. Productivity is an ebb and flow. If something is always getting faster, it leads to burnout.
So that’s the craic. That was strangely profound. Follow us @ServerlessEdge on X and visit TheServerlessEdge.com blog to like and subscribe.