Developer Productivity and discussions on developers and productivity have 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.
Serverless Craic from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube
Developer Productivity and discussions on developers and productivity have 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.
Serverless Craic from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube
Welcome to the next edition of Serverless Craic.
Michael O'Reilly:I've been playing around with (shout out to Alberto Brandolini and aggregate modelling) and challenging myself with aggegate modelling technique and practice, which has been good.
Mark McCann:Lots of good mechanisms and practices being embedded into teams. I was envious of your Friday aggregate modelling session.
Dave Anderson:One thing that's been in the news recently is'developer productivity'. There was a an interesting article that McKinsey brought out on a framework for measuring developer productivity. I am 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 brilliant, super smart 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 pretty good read. I find it surprising that 'developer productivity' has never gone away. You heard people talking about this in the 80s and the idea of paying devleopers by lines of code. And it was even rubbished in the 80s as a really stupid thing to do. There's a famous story about developers removing bad code from the code base and having a 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. So it strikes me as strange, that is 2023, we are having the same discussion.
Michael O'Reilly:My first reaction when I read both articles was that it feels like something from the 90s. 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 huge amount of thought work required to ensure you're doing things the right way.
Dave Anderson:If only there was a company will to help you write code, like Thoughtworks! There's always been developers who think we get paid to write code, so we write code all day. We talk about the fact that it is not what the job is. We're software engineers, not developers, because you're solving problems. If you're paid to just write code, it is easy to automate and replace that. It's not where your value is. Of course, you often write code to solve something and that's an important 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 disjoint between them. In his article Dan identifies several weaknesses and factual errors. It's definitely worth reading both Dan and McKinsey's articles. What gets me is the fact that McKinsey area smart company who see a massive demand for this because there are lots of companies 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!
Mark McCann: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 they deliver 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 centre for some organisations, but you don't want to measure 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?
Michael O'Reilly:It worries me that companies would use that sort of framework. And evaluate developer proficiency based on number of lines of code. I don't know about you, but I'd question my ability to perform in such an organisation. Because it should be about the outcomes and what problems we are trying to solve. How are we approaching those problems by beginning to iterate and experiment. Good outcomes for the most part do not always involve code.
Dave Anderson: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 organisations, and somebody says, "We need a document management system". There are two paths. You can figure out what document management system you need and start building it. Or you could say, 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 don't know where that would stack up with developer productivity. But it's extremely productive to not build it.
Michael O'Reilly: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 in order to correct the situation. And it's way too late for a successful or good business outcome. They have focused you 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?
Mark McCann:You don't want to beautifully engineer with developer metrics and productivity for a problem you don't actually have. Your developer productivity metrics are fantastic but you're not delivering key business outcomes or mpact because you haven't thought about your clarity of purpose upfront. And you haven't thought about how your users, their needs and key indicators of progress.
Michael O'Reilly:Let me pose a question. You're in an org, working the way you would work, 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 serious problem. If your most experienced engineer's code commits go through the roof or elevate in an abnormal way, there's something weird going on.
Mark McCann:You need your best engineers, your best thinkers doing the thinking upfront, and not actually typing for the most part. Ad you need your best developers or those who can think about the problem helping the team address that problem with the least amount of code.
Dave Anderson: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 different colour, and it'll generate a piece of code. Or here's a piece of code in Rust rust, tell me what this does. I don't think that's going to help with a legacy code base with tens of thousands of lines of code. 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.
Mark McCann:There are productivity gains to be had 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 this stuff, then you're optimising the wrog part of your value chain.
Michael O'Reilly:I don't want to be alarmist but it would make good developers better and bad developers worse if you are measuring developer productivity by the lines of code. If you're shipping code that you haven't written, and you don't know how it's hanging together faced, there's alot of risk involved. Good 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.
Mark McCann: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 behaviour are you implementing? What KPI are you influencing? And what users and needs are you delivering these behaviours and capability for? Is it okay to let them generate the code quickly. If it frees you up to think about the fundamentail things, then maybe it's a net positive.
Dave Anderson:It's the hard part. Ask you team: 'What's your business KPI?'. It's essential that the team knows, and they're clear on what they need to build, they know 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 go 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 don't know why. it leads back to the Northstar and having clarity of purpose. It's very difficult to put that into develop productivity. Because you need to be joined up. When a piece of work gets to the team, if there's clarity and the team know how to talk and find out what it is, they can solve the problem. Thorough understanding of the problem does not have a magic tool or developer productivity technique.
Mark McCann: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 not be a problem your release process or cloud infrastructure could be the problem. Any number of things could be barriers to true developer productivity. Writing code may not be a problem. You might need to address other things in your ecosystem.
Dave Anderson:It may even be a function that is outsie engineering! Slow is smooth and smooth is fast, is interesting and understanding how you do certain things. Slowing down to probe things with the Northstar or think about your design. They're all extremely useful things to do. By identifying inertia barriers, your execution can go really fast. There's a shape of productivity that is not rapidly decreasin. 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.