Software Architecture for Productivity: Why Batch Size Matters

One of my jobs in high school was as a picker at a warehouse for hair care products. Salons would call in orders for color care, straighteners, shampoos or whatever. The call center operator would enter the order into a green screen (it was the 80’s) and the order would print out on a dot matrix printer in the warehouse.

As a picker my job was to tear off the pick sheet from the printer and fill the order. It was easy. The pick sheet listed the exact aisle, shelf, bin, and quantity for every item on the order. If you followed the pick sheet top-to-bottom, you would never have to backtrack in the warehouse, and at the end of the pick sheet, you would end up close to the packing station.

At the packing station, I would pack a box, tape it, label it, and load it onto a wooden palette. Then I’d head back to the printer, tear off another pick sheet, and start all over again.

In terms of emotional management, this is one of the best jobs I’ve ever had. The entire system was designed to promote flow. Every time I placed an order on a palette, I got a sense of accomplishment, and a little hit of dopamine as a reward. There was no ambiguity, no hoarding, no politics, none of the worthless ceremony that makes “corporate” jobs so tedious. At the end of every shift I clocked out, feeling good about myself. The more orders I filled, the better I felt.

But as Longfellow observed, into each life some rain must fall. In addition to hair care products, this warehouse also drop-shipped custom signage. Most of the signs were styled after a salon’s logo, so each one was a different size, weight, and shape. Whenever I drew a pick sheet with a custom sign order, my heart would sink into my shoes.

The signs were a pain because they wouldn’t fit into a standard box. In order to ship one correctly, I would have to cut cardboard apart and fashion a container to fit. If the sign was fragile, I had to devise appropriate padding. If the sign was heavy, I had to reinforce the packing at the bottom. If the sign had neon elements, I had to reinforce all the walls. To package a sign correctly could eat up several hours of my shift.

But it gets worse. To prevent breakage, each sign had to be placed alone on a palette, which meant less stuff could go out on each truck. This created back pressure. Depending on overall order volume, the back pressure might cause palettes to pile up in the warehouse. We didn’t have any extra space on the floor, so if that happened, the pickers were basically done for the day.

This is why batch size is so important in delivery logistics. If you have high variation in batch size, then batches with the highest degree of uncertainty distort the mean time to completion, making it impossible to estimate, forecast, or plan with any degree of confidence.

Anyway, whoever designed this particular warehouse was a productivity genius. He or she normalized the complexity of each task to the point where even high school kids and barely literate ex-cons could do the work efficiently. (I learned at this job that warehouse picking is one of the few jobs available to ex-cons)

But…whoever decided to drop-ship signs from the warehouse was not a genius. By introducing variation in batch size, he or she sub-optimized the entire system around a single revenue source. If you factor in warehousing and transport costs, the drop-ship business was very likely net-negative.

Which brings me, at last, to software architecture.

There is a common analogy that compares software architecture to physical architecture. In this imagining, the job of a software architect is to create blueprints. The idea is that engineers should be able to turn the blueprint into working software, just as construction workers use blueprints to build a house.

I don’t like this analogy because buildings don’t go anywhere once they are built. Building houses is hard because supply chain management is hard. Having a nice blueprint doesn’t help you if you can’t get materials to the building site at the right time is.

Supply chain management is not a huge problem in software, because for the most part, the raw materials are in our heads. In software, the key logistics problem is delivering features to customers. Getting the right feature in front of the right customer at the right time is vexingly difficult.

In order to do it well, you need to normalize task complexity in your software production line. An early career engineers should be able to take the top item off the to-do list and do the work quickly, with minimal supervision.

This is effectively impossible unless your architecture is easy to batch. Uniform batches are easy to sort and estimate, which means managers can plan, forecast, and estimate more confidently.

But the real beneficiary is the engineer. If your architecture is easy to batch, you have normalized the complexity of each task, which makes it easy for even early career engineer to be happy, focused, and productive.

As an architect you know you’re winning when the production line is humming. Your engineers should be able to merge a pull-request every day. If they can’t, then your architecture likely cannot be batched easily, which means your engineers are miserably cutting cardboard apart to fit weirdly shaped signs.