There’s no end of bullshit laws and principles in the programming industry that say the equivalent of: writing code is the easiest, smallest part of making software, it’s dealing with people and working out the people-bugs that’s the problem. This is the old “the error was between chair and keyboard” quip: humans.
So, much of the frameworks and processes we’ve developed over the decades have been all about those “between chair and keyboard” issues: communication and coordination between different humans and silos, so you have microservices and ways to to decouple dependencies; code must be maintainable and observable so that humans can extend, fix, and diagnose it; product managers need to synthesize what customers want (and what will sell well/fit into business goals) in a way that developers will understand and decide what features to work on; and so forth.
I’m going to push a point Dan made recently (see video above) further than he did:
We’re spending a lot of our time getting AI to program like humans instead of figuring out the optimal way to that AI wants to program. Each role in the SDLC is thinking on how that role fits into AI-driven programming. We do a lot of “spec driven” AI development.
As Dan points out, there’s a middle-ground he’s been using that relies more on just little reminders and standard operating procedures in project, and then skills that codify how to do repeated processes.
Consistency
You certainly want consistency in how your AI codes and, otherwise, does work. You don’t want it doing it differently each time.
I don’t really program when I’m using AI. Sure, it programs for me, but I’m not writing applications, I’m using it everyday, almost “all the time” to get shit done. How it wants to program isn’t really my concern. That repeatability and consistency is, though.
Getting consistency is what ends up taking the most effort and has the biggest pay off, and, conversely, downside.
Sure, but what about enterprise?
For a solo developers, Dan says, maximum spec driven development can be too much. He concedes that larger enterprise teams would probably benefit. This is where I think we’re trying to impose the human way of developing onto AI coding.
Many of those humans are there to make up for the need to coordinate between all those humans and the code they write. You know, the account ledge team in Reston needs to coordinate with the bill payment team in Dallas. We need to sync up the backlog from the product manager in San Francisco with the dev team in Cork. And then there’s coordinating with UI.
So much overhead.
But if we started with a clean-slate and just, say, a product manager or a product-leaning developer and a Max account, what would it look like if they only added people when needed?
I suspect it’d be a different way of programming and something closer to what Dan is talking about, even at the “big enterprise team” level.
There’s another IT law/hand-wave that goes something like this: 80% of work is maintenance, we never get around to the interesting work. There’s no time to implement new features, to change the software instead of just “keeping the lights on.”
Which is to say, there is no end of things to work on, many of them important and constantly stalled in favor of, like, bugs and security. We need more programmers, and overtime we’ve seen that you can’t make more programmers – that’s why they get paid so much, there aren’t enough of them.
Well! Now’s our chance. If we foist our current way of working onto this new way of programmer we might end up with the consequence of another IT “law,” Larman’s Law: the same exact thing as before.
Leave a Reply