Welcome to the finale of my mini-series on licensing software engineers. Part one talked about how this would apply to AI self-regulation, and part two shared Steve McConnell’s 1999 proposal that should’ve been bigger than it was. Today I’m retelling a famous parable of agile software development, which encourages software engineers to define their own (hopefully high) ethical standards. Enter… the Squirrelburger.
The Squirrelburger question
Suppose you own a hamburger restaurant famous for your excellent beef. Late one night, after your team has gone home and you’re about to close up, a customer comes in. He tells you he’s travelled to your city from far away just to try its greatest dishes, it’s his last night in town, and begs you to please make him one burger before you head home. Sympathetic to his passion for food, you agree, and head into the back to get cooking.
Due to the secrecy you keep around your burger recipe, you’ve built your restaurant so it is impossible for customers to see or hear anything about what you are doing when you’re at the grill. Which is good in this case, because you curse loudly when you realize that you are totally out of beef. What are you going to do? You promised this man a famous burger.
You look around frantically, and notice that outside your back door, a dead squirrel lies on the ground by the trash cans. It’s clearly freshly dead. Not spoiled, not poisoned. Totally good; just dead.
You have a stroke of culinary inspiration. You could grind up the squirrel meat and make a burger out of that. The guy out front won’t see or hear you do it. He has no idea what your burgers are supposed to taste like, so he’ll never know that you served him a squirrelburger instead of a beefburger. He’ll eat and leave the restaurant a satisfied customer, and you’ll make a little more money. You’ll be the only one who knows he was served an inferior product.
Do you serve him the Squirrelburger?
Um, so what does this have to do with software?
The squirrelburger parable comes from Ken Schwaber, the co-creator of Scrum, one of the leading agile software development methodologies that caught on in the 2000s. I heard him tell the story when he helped DoubleClick move all of its engineering teams onto Scrum around 2006. For those of you who don’t work in the field, here’s a simplified explanation of how software development and squirrel meat connect. [Software professionals: I’m about to gloss over a lot of nuance, but I’m trying to keep this brief, so cut me some slack.]
Building software always involves some combination of similar steps: gathering requirements, designing the software, estimating the cost and schedule, writing the code, testing it, releasing it, and so forth. Any software development methodology is just a specific approach to emphasizing, combining and ordering the same basic steps. Even AI-powered software development is mostly just about automating these steps with LLMs, agents, and so forth.
For a long time, the dominant methodology was “waterfall development.” In waterfall, each step gets completed before continuing to the next one, and you don’t go backward. You don’t start designing your software until you’ve finalized the requirements, you don’t start writing code until you’ve finalized your design and estimated how long it will take to build, and so forth.
In theory, this is a prudent approach that gives you useful planning information up front. In reality, waterfall development tends to go badly wrong. It’s impossible to actually figure out everything about complex software in advance. The inevitable requirements or design misses are incredibly expensive and time-consuming to fix when they’re discovered way downstream. Large waterfall projects have an infamous track record of running months or years late, or failing entirely.
Agile development is an attempt to fix this by breaking big projects down into many small chunks. Instead of trying to document everything before you start, you just figure out the most important piece of software to build next, do that, see how it went, and adjust course for the next iteration. Teams that adopt agile methodologies find that they move faster even without up-front planning, because they can make adjustments and fix problems with every iteration, so they waste less time on work they had to throw out later.
The details of Scrum, the methodology DoubleClick chose, aren’t super important to this story, but a few key terms are helpful. Scrum calls its chunks of work sprints (usually lasting one month). Each sprint, everyone agrees to a set of user stories that they’re going to try to finish and doesn’t change the list until the next sprint. Scrum also defines strict roles: the product owner writes the user stories, the engineers decide which user stories they will commit to, and everyone listens to the scrummaster who keeps the process on track, but doesn’t decide what goes into each sprint.
Software engineers are burger chefs
Back to the squirrelburger parable. Hopefully you agree that you absolutely cannot serve the customer a squirrelburger. If you think the squirrelburger is A-OK, please stop reading this newsletter and seek help.
Schwaber told this story to encourage Scrum engineers to hold themselves to the same standard as the burger chef. Like the squirrelburger customer, product owners have no way to know what’s in the software that the engineers deliver. Only the engineers can decide whether to deliver a solid product or a house of cards.
Like McConnell in After the Gold Rush (see last week), Schwaber also used the story to connect software engineers to other professions. We trust that architects have ensured the buildings we live and work in won’t collapse on our heads, even though we can’t see the wood and steel holding them up. But in the absence of licensing, software engineers don’t get the trust and deference that we give to other professions like architects, so they have to rely on their own professionalism.
This is harder than it sounds. Software engineers are under constant pressure to cut corners. Executives and customers are always pressing them for more features and faster delivery, like the late customer begging for one more burger. It is no surprise that many engineers are tempted to give in, do a half-assed job to meet their boss’s unreasonable schedule demands, and say it’s not their fault if things go wrong. That’s the recipe for squirrelburgers.
The squirrelburger can apply to ethics, not just quality
For me, the squirrelburger story should inspire engineers to think about a broad range of ethical dilemmas beyond basic quality. Dark patterns, weak security, and vulnerability to abuse are today’s squirrelmeat, and they are being mixed into products every day for the sake of growth and revenue.
I wish that more software engineers would simply refuse to build ethically-flawed software, but I have no standing to lecture them about ethics when the worst thing that will happen to me is maybe losing some newsletter subscribers. Things are tough out there for working engineers in the AI age. The workload is insane and layoffs are rampant. There’s a real danger that an engineer who refuses to ship a squirrelburger today could lose their job.
This is why my first preference is still for a licensing regime to give senior engineers the backing of professional societies and regulatory rules when they stand up for what’s right. In the absence of that, if even one good engineer is inspired by the squirrelburger story to refuse or redesign a bad project, they will have made the Internet a slightly less horrible place. We owe brave engineers like that our gratitude and support. And maybe a tasty burger.
Ideas? Feedback? Criticism? I want to hear it, because I am sure that I am going to get a lot of things wrong along the way. I will share what I learn with the community as we go. Reach out any time at [email protected].
