AI cuts software developers some slack
InfoWorld ·
My mom used to say that Hodges’s law was “Junk expands to fill the space allotted for it.” We lived in three houses over the years, each one bigger than the previous house as our family grew, and each house became just as full of junk as the one before it. My mom was echoing C. Northcote Parkinson , whose famous law said the same about work—that it expands to fill the time given to get it done. In other words, if you say a task will take a week or two weeks, you’ll be right either way. We all know it is true, right? So what does Parkinson’s law mean for the productivity gains that we get from agentic coding? For the sake of argument, let’s say that we are five times more productive with coding agents. Instead of fixing one bug a day, we can now fix five. Instead of doing three story points a week, we can now do fifteen. What actually happens? Leisure happens Well, initially, I think it means we’ll get more free time. The productivity gains that turn eight hours of work into two won’t suddenly mean we get six more hours of work piled on. Instead, we get what Fabian Stelzer has dubbed “ dark leisure ”—the notion that your manager doesn’t know yet that you’re five times as productive, so instead of doing five times the work, you speed up by a factor of only two and surf the web the rest of the time. Your boss sees more work and you keep up with the latest cat memes. But that will catch up with us eventually. I’ve written about the Jevons Paradox , and that comes into play as much as Parkinson’s law does. Gradually, as managers and ambitious devs start putting agentic tools to work more efficiently, we’ll see demand for more software, and dark leisure time will get filled with more work. We’ve seen this before. Back in the early days of Windows, it was a serious pain to create a simple Windows application. You had to write many lines of C/C++ code just to make a blank form appear on the screen. Adding a simple button was even more effort. Eventually, though, tools like Delphi and Visual Basic made putting a button on a form child’s play. When creating Windows apps became easier, the number of Windows applications exploded, and their user interfaces grew more complex. Early Windows apps had fairly simple user interfaces, but it wasn’t long before the increase in productivity allowed us to build complex UIs with all kinds of controls and toolbars and the like. The same thing happened with the web. Meandering through the deep, dark caverns of the Wayback Machine reveals many primitive-looking websites . Work rushes in So we have this pattern—productivity gains lead to more software and more complexity. Work expands to fill the time allotted for it. The question then becomes: when one developer can do the work of five, will firms want fewer developers or more output? I strongly believe that it will be the latter—firms will want more output. Businesses will realize that they can plow through their backlog, pleasing customers. Intrepid entrepreneurs will realize that they can bring their crazy ideas to market in days or weeks instead of months or years. Generally, thinking “I can have one guy do all the work this team of five can do” is rather small-minded, and the marketplace doesn’t reward small-mindedness. But here is what I think is the real problem. Sure, moving into a bigger house made room for a bigger family, but each bigger house was more cluttered than the last one. Larger houses contain more things and require more work to keep them clean. Similarly, as software expands to fill the time left by dark leisure, it, too, will grow more cluttered. Working five times faster could very well mean that technical debt piles up five times faster. And of course, we can fix technical debt five times faster as well, so who the hell knows what that will all lead to. I think it will lead to the same thing it has always led to. We’ll be busy. We’ll build bigger and cooler things, and it will all still take the time that we allot for it to get done.
My mom used to say that Hodges’s law was “Junk expands to fill the space allotted for it.” We lived in three houses over the years, each one bigger than the previous house as our family grew, and each house became just as full of junk as the one before it. My mom was echoing C. Northcote Parkinson , whose famous law said the same about work—that it expands to fill the time given to get it done. In other words, if you say a task will take a week or two weeks, you’ll be right either way. We all know it is true, right? So what does Parkinson’s law mean for the productivity gains that we get from agentic coding? For the sake of argument, let’s say that we are five times more productive with coding agents. Instead of fixing one bug a day, we can now fix five. Instead of doing three story points a week, we can now do fifteen. What actually happens? Leisure happens Well, initially, I think it means we’ll get more free time. The productivity gains that turn eight hours of work into two won’t suddenly mean we get six more hours of work piled on. Instead, we get what Fabian Stelzer has dubbed “ dark leisure ”—the notion that your manager doesn’t know yet that you’re five times as productive, so instead of doing five times the work, you speed up by a factor of only two and surf the web the rest of the time. Your boss sees more work and you keep up with the latest cat memes. But that will catch up with us eventually. I’ve written about the Jevons Paradox , and that comes into play as much as Parkinson’s law does. Gradually, as managers and ambitious devs start putting agentic tools to work more efficiently, we’ll see demand for more software, and dark leisure time will get filled with more work. We’ve seen this before. Back in the early days of Windows, it was a serious pain to create a simple Windows application. You had to write many lines of C/C++ code just to make a blank form appear on the screen. Adding a simple button was even more effort. Eventually, though, tools like Delphi and Visual Basic made putting a button on a form child’s play. When creating Windows apps became easier, the number of Windows applications exploded, and their user interfaces grew more complex. Early Windows apps had fairly simple user interfaces, but it wasn’t long before the increase in productivity allowed us to build complex UIs with all kinds of controls and toolbars and the like. The same thing happened with the web. Meandering through the deep, dark caverns of the Wayback Machine reveals many primitive-looking websites . Work rushes in So we have this pattern—productivity gains lead to more software and more complexity. Work expands to fill the time allotted for it. The question then becomes: when one developer can do the work of five, will firms want fewer developers or more output? I strongly believe that it will be the latter—firms will want more output. Businesses will realize that they can plow through their backlog, pleasing customers. Intrepid entrepreneurs will realize that they can bring their crazy ideas to market in days or weeks instead of months or years. Generally, thinking “I can have one guy do all the work this team of five can do” is rather small-minded, and the marketplace doesn’t reward small-mindedness. But here is what I think is the real problem. Sure, moving into a bigger house made room for a bigger family, but each bigger house was more cluttered than the last one. Larger houses contain more things and require more work to keep them clean. Similarly, as software expands to fill the time left by dark leisure, it, too, will grow more cluttered. Working five times faster could very well mean that technical debt piles up five times faster. And of course, we can fix technical debt five times faster as well, so who the hell knows what that will all lead to. I think it will lead to the same thing it has always led to. We’ll be busy. We’ll build bigger and cooler things, and it will all still take the time that we allot for it to get done.