Build a Michelin star kitchen, not a software factory
Building software isn’t a factory job. Automate the boring stuff, and spend the time you save on iteration, polish and your own judgement.
Listen5:04So, I wanted to talk a little bit about software factories. They’re all the hype. Everybody who’s anybody who’s cool is building their own software factory.
However, I think it’s a load of baloney. Hear me out.
Factories are the automation of repetitive work. And I think that can and should happen in things like manufacturing, where there’s a predetermined series of deterministic steps to produce an output, the same output every time.
But when you think about something like knowledge work, like creating apps or writing code, it’s not a deterministic process. There’s not one solution. There’s not one way to do it.
Sure, in software engineering we always try and create systems so that we don’t have to make a million decisions every time we do something. We stick to rules and patterns that work, good abstractions and all of that. But I think it’s a bit of a fool’s errand to think that you can fully automate it.
And I’m pretty sure I know, because I’ve tried. I’ve tried very hard to do this, and the results are just not what I want.
I think it’s a similar discussion to the move from waterfall to agile in software.
Waterfall was: we spend a crazy amount of time up front designing the system, making decisions about how it works. The rules, the dependencies, everything. And then we just build it in one go, but it takes ages. It always takes longer than we expect. It’s never delivered on time, never delivered as planned. We take, what, a year to build a thing, and then we realise it’s wrong, and then it takes another six months to fix it.
So that’s the old, old-school way, and you can clearly see why it’s not a good idea.
Then compare that to agile. I’m not getting into the religion of it, but basically, it’s all about iteration speed. Can I build the core, the shell of the idea, in a terribly hacky way, to get it to work and see how it feels? Don’t plan any more than that. See how it feels, and the next thing you need to build becomes obvious.
You do these small cycles, you get feedback quicker, you keep iterating and fixing problems, and you might end up somewhere completely different to where you planned to go. And that’s okay. Actually, I think that’s right. I don’t think you can plan a software project in one go and just build it. It never works that way. You always end up changing things. And I think that’s for the better.
And that’s what I think about agents too, and doing stuff in the world of AI. You see these people on the internet who say they have software factories building stuff for them. Or they say they’ve fully automated X, Y or Z. Or that their AI agents build businesses for them, businesses that make money automatically, with barely any input from them.
All I can say about these people is they must have a very low bar for quality.
Because if I just tell it what I want, sure, it can build something that’s kind of functional. But it’s not the way I want it to look, or it’s not quite functional, so I have to change it, and I tweak it, and I tweak it. Even with all the advancements, and all the extra stuff I can get done because of AI, I still can’t fully automate building things. It’s still iterative. It still requires my input. It still requires changing direction, polishing, revisiting, all of that stuff.
So I like @poteto’s idea. Instead of a software factory, I’m going to build my own Michelin star kitchen.
You wouldn’t think of a Michelin star kitchen as a dull, boring, lifeless place that only works to exact measurements. You think of a Michelin star kitchen, and it probably has some incredible chefs. And I bet they’re not robotic. I’m sure they’re reliable, but I bet if they didn’t have an ingredient, they could just conjure up something else incredible. They also know when to lean on tools: what to automate, and where their judgement and input drive the biggest results.
And I think that’s exactly what we need to do. We take advantage of the tools to write the code faster. That doesn’t mean we don’t need to give our input, to iterate, to change direction. I think we can do that even more: more steps, more iterations, more polish. We can get to something that previously would have taken way longer, or that we wouldn’t have got to at all, because we couldn’t have put in the time to get there.
So I hope you can start to think about it that way as well. Or maybe you already do.
Automate the boring stuff. Allow yourself to spend more of your time injecting your own expertise, judgement, experience and uniqueness into what you’re building.