The Summer of Radiators and Incidental Complexity

During the summer between high school and college, a very important summer in most people’s lives, I worked as a radiator mechanic.

The guys I hung out with in high school talked mostly about two things: girls and cars, and the latter was the only thing they could speak of from any experience. Me? I knew nothing about girls and even less about cars.

Wilkes Radiator

At the start of the summer, I worked at a lumber yard, but when they cut hours down to just a handful a week for the summer crew, my uncle offered me a job to help out at his radiator shop and as a kid that needed gas money, I accepted, even though I didn’t know the difference between a radiator cap and a hole in the wall.

There were three of us in the shop: my uncle Wayne, Terry, and me. Terry told me that God helped him find the money to buy the red 1969 Gran Torino he drove to work every day. With a car that nice, I believed him.


Every customer’s issue was a puzzle and I loved solving these puzzles.

People would come in with a complaint, usually that their car was running too hot or too cold.

From these high-level complaints, we’d start digging down, armed with the knowledge of how the fluid, heat, and metal played off each other.

Car running too hot? Make sure there was enough fluid. If the coolant looked ugly brown instead of neon green, there was probably chemical build-up in the radiator core. If the fluid looked okay, the thermostat was probably busted since it wasn’t opening up and letting the hot water into the radiator to cool.

That’s how every job worked. If this, then that. Just like the machines themselves, diagnosing them became mechanical.


The heating-and-cooling system of every car is basically the same. They all have radiators, thermostats, water pumps, and heater cores. A fresh-off-the-lot Honda’s radiator works the same way as the radiator in a 50-year old Chevy truck.

Everything else around this simple system has changed, though.

Someone would bring in a newer-model Honda Civic and want their heater core replaced. (The heater core is a mini-radiator that sits behind your dashboard that blows hot air when you turn the heat on.) We would quote a full day’s labor to do this. This same job on any vehicle before the 1980s would be more in the range of an hour’s worth of work.

Honda Civics were built to be small, light, safe, and environmentally friendly. These are all good things but the complexity these new features added made the other simpler systems more expensive to maintain.

In this case, since these things were built so compactly, you’d have to remove the entire dashboard of the car, including rolling up the carpet and removing pieces of the door, keeping track of dozens of little screws, panels, and trim pieces, just to get to the heater core.

In older trucks, built with neither weight nor size considerations, the heater core was usually behind a little panel under the passenger side dashboard that involved removing four screws, popping the heater core out, putting the new one in, and then replacing the panel. Easy.

Some of the jobs on newer cars would actually be a significant portion of the total value of the car. If it costs you several hundred dollars to replace a fifty dollar part on a car that’s only worth a couple thousand dollars, people often decide that’s it’s just cheaper in the long run to just buy a whole new car.


Even though the basic concept of moving water through an engine to control temperature has held across a 100 years of automobiles, cars in the past 15 years have made working these jobs longer, more cumbersome, and thus more expensive.

Like a lot of pieces of modern culture, things seem to be built to be replaced, and not to fix. Some people may attribute this to our “throw-away culture”, but I think that it’s more of a symptom, and not the cause.

In the cause of advancement, we’ve built things that are cheaper to replace than to fix.


This relates perfectly to building large software systems.

You often hear tales of the Big Rewrite: when a group decides that in order for a piece of software to be improved, it needs to be rewritten from scratch.

Their problems don’t exist at the component level. Writing to a database probably works fine. Displaying a web page probably works fine. Uploading a photo and storing it away probably works fine. But when these things need to exist alongside one another, software people tend to make them unnecessarily depend on each other.

And when things are tightly coupled, you can’t change one without affecting other seemingly unrelated things, and not without great cost.


Complexity of one system affects complexity of the overall system in often unforeseen ways and most complex systems are made up of simple, but overlapping, systems.

I’m sometimes nostalgic for when I was debugging and fixing a physical machine, since dealing with concrete matter made thinking through these complex systems easier.

But when you’re dealing with such an abstract thing as code, it’s easy to write yourself in a corner, where you sometimes have to remove the whole dashboard just to replace a cheap part.