Main Article View

Evolution of Pizza Engineering

Published: 05 July 2022


So, you own a pizzeria. What do you sell? Simple. Pizzas with a variety of toppings.

How much, though, would you sell a single pizza? I don't know; I haven´t had the opportunity to own a pizzeria. But we can assume that the dough, the ingredients for the toppings, the fuel that keeps the oven at the right temperature, the time and expertise of the people who make the pizza; they will all be factored in when determining the base price for each pizza to be sold. Then the markup.

Now, say that in the course of a year, you find a more economical way of getting the topping ingredients. For example, when you started, you'd have spent 5,000.00 Pesos for the onions, tomatoes, ground beef, etc.; and on top of that, 200.00 Pesos for gas going from your place, to the market, and finally to the pizzeria. But on your second month of operation, you become friends with a couple of farmers— one who grows the veggies, one who grows livestock— and they offer to supply your ingredients at a price significantly lower that you've been spending at the market. It will reduce the base cost of each pizza that will be made from that point on. The question now is: do you reduce the price at which you sell each pizza?

One might argue that if you were an honest woman, you should reduce your retail prices. On the other hand, since you are getting better quality ingredients in terms of freshness, at the very least, you might even want to raise your retail prices a bit. My guess is that your decision will be based on how far into the future you can see.

If every time you are able to reduce your costs without sacrificing quality, you feel you ought to reduce your retail prices, I don't think you pizzeria is going to last long. You need to incentivise improvements, not penalise them.

If you feel conscientious about making more while you're spending less, there are other things you can do to make things right. Offer to pay the farmers a bit more for the ingredients that you buy, for example. If the people who prepare and cook the pizza gain more experience doing what they do, and they continue to stumble upon ways that make their life easier, allow them to take longer breaks. As long as those people are able to produce products as you need them, let them relax when they want to— it makes no sense to make extra pizza when all orders are filled anyway.

Now, you own a software engineering company. What do you sell?

Software is a lot more abstract for most people than pizza is. Even for people who have been in the industry for a long time, its hard to quantify the value of software— how to present it as a commodity that people will actually pay money for. So, if you're lazy or just don't know where to stand to have a different perspective of the whole thing; the tendency is to just charge people relative to the time you spend in delivering the features and fixes that they require.

But if software engineering were really, at its very core, problem solving; why should solutions that are provided faster be cheaper than solutions that materialise longer? I think that charging clients based on the time spent in arriving at solutions is just wrong. Companies or individual engineers need to charge based on the gravity of each problem; to ask the client, “how much is this solution worth to you?”

This isn't an original idea.

I've worked in a variety of companies; one as small as having less than 10 employees working together on a dining table, one as big as having almost 40,000 employees globally, and several in between. Of those companies that practice the Agile methodology, never were hours spent working on each task essential in computing how much we got on payday. And while I was never involved in negotiating contracts, we developers have always had the opportunity to contribute in the determination of how much a project is worth. That opportunity comes in various team meetings where we break down the essentials, figuring out what tasks depend on the completion of others, agreeing on deployment and testing strategies, and how long we have to provide for “hyper-care” once everything is running in production— you know, just engineering stuff.

Does time factor in anywhere? Only in determining the stages or phases of completion. For example, if we were to build something from scratch, we'd ask ourselves what underlying IT infrastructure will be needed; how difficult will it be to set up each part of the infrastructure; and based on that difficulty, how much time will it take to finish setting the infrastructure up and to test that it works? And the answer will always be a rough estimate: three days, one week, two weeks, etc. I've never seen an estimate made in hours.

Often, the people designated to set up the infrastructure will finish ahead of schedule. What they do is notify the team that they can start using it when they're ready. But what would they be actually doing while development or testing is going on— remember, they're still part of the team. They'll probably be on standby, waiting to provide help when necessary.

Standby. In one company I worked at, we called it “capacity”. It sounds really nice.

What do we do with “capacity”? Ideally, we'd be working, albeit unofficially, with other teams; providing support, doing code reviews, maybe helping out colleagues with their coding problems. We're also encouraged to take informal online classes, browse tutorials, just brush up on tech things that may be useful in the future. It varies. But while you're still in the team, that should be your focus— even if you have to do nothing.

I digress.

Software is a lot like pizza. Making software has a lot of costs associated with it and if you want to make a profit, you should be able to calculate those costs; determine an acceptable markup price; and, instead of penalising quick turnovers made by competent employees, incentivise process improvements and expertise— and save on costs associated with health issues and high attrition rates.

You don't sell pizzas based on how long it takes someone to make it. Why do the same for software?