Model Railroads and Technical Debt

Model railroading has taught me a lot. I can identify solvents by smell… and get nostalgic when I smell Dio-sol or Dullcoat. I learned how to repair mechanical devices, and convinced someone I might be a keeper when I fixed her CD player. Most importantly, I learned how to be kind to my future self, because I try to remember to make it easy to fix stuff on the model railroad in one year… or in ten years.

That’s a common lesson for model railroaders. Model railroads are long-term, large projects. The model railroad we build is going to last for several years, and we’re going to be expanding and repairing it along the way. The design and implementation choices we make years before will curse us years later. One badly placed switch machine is going to leave us with a sore back every time we repair it. Each time we cut corners wiring, we’re just forcing future-us to try to figure why that blue wire’s hanging loose, or remembering the wire color we used when we didn’t have black wire available. Every bit of track we can’t reach will be our bane every time a locomotive stalls or the track needs cleaning. Every model railroader has that moment of “what was this purple wire for, and where does it go?” early on in the hobby. After that we realize the benefit of using standard colors for wires, providing good access both to the track and to the mechanical and electrical parts below the layouts, the importance of labelling connectors and writing down designs - doing anything we can to avoid past-us making life difficult for future-us.

It turns out that’s a pretty useful skill in the real world, too.

I got to move some equipment I’m running into a new computer room the week before last. After I’d finished wiring it up, I asked one of the IT guys for help with something else. When he came over, he immediately commented on the state of the rack. “Wow, you’re using cable ties. And your wiring is neat - not like that other engineering rack.” He showed me the proper way to cable tie wire loops was with two ties, but he seemed pretty impressed that a software engineer was trying to keep wiring neat. The other rack, which I’d just moved my stuff from, had so many cables coming out the back that I couldn’t reach in to disconnect my machines. To be fair, the other folks in the rack were reconfiguring their stuff daily, and had a lot of connections to support; I was setting mine up for a single, long-term configuration with a much simpler configuration. Google’s original “cork board” server racks - now in the Smithsonian - highlight that you can be pretty successful even with messy wiring.

But model-railroader me was also wiring that equipment in the same way I’d want to wire the model railroad. I remembered the messy wiring on my first model railroad, and the pain I caused future-me. As a result, I made sure to steal cable ties from random benches, chose different colors for all my different cables, and neatly routed the wiring so I could get to the equipment and track down cable paths. Future-me (or future team-mate reaching in that same rack) should have an easier time, all thanks to past-me placing switch machines in inaccessible chambers between sheets of plywood, or tracking down intermittent shorts when teenage-me was splicing together wires with a couple of twists and bit of masking tape for insulation.

We worry about the short-cuts in computer programming just as we do in model railroading or in physical engineering. It’s become a popular topic in software engineering research as “technical debt” - delayed cleanup or quick-and-dirty implementations that complicate or block future changes. There’s even mini-conferences on the topic with research papers titles like “How do Software Practitioners Discount the Future?” Real engineering has technical debt too - think how commuter rail choosing to use low-level platforms (boarding at ground level) might never be able to move to high-level platforms (level surface from platform to passenger car) because of the problems transitioning from one to another. However, software tends to have more of these kinds of problems because everything’s up for grabs in software - we can build stuff any way we want, we don’t necessarily have conventions about how to do common tasks, and it’s often difficult to see those shortcuts from the outside. It’s common to tie together two bits of software with the ugliest, most fragile hack “that’s only needed temporarily”, just as I used alligator clips to temporarily tie together the power for two strips of LED lighting today. That’s less common in more traditional engineering disciplines; as far as I know, petroleum engineers never say “Joe, you sure you want to use cardboard tubes to join those two parts of the refinery while you’re testing?” (If you want a more nuanced argument about technical debt in software, read Kellan Elliot-McCrea’s argument that the term technical debt is mixing up a whole bunch of reasons why we have problems maintaining the things we build.

My current job involves writing tools to help software engineers build better programs: programs to test that the software can be built correctly, runs correctly, and has the performance we expect. Because our team has to have our infrastructure ready so that everyone else can make progress, that means we’re often building stuff as fast as we can, cutting occasional corners, and incurring technical debt so everyone else can build the things we sell. I occasionally take the same shortcuts in model railroading. Occasionally I route wires in ways that’ll make it harder to track down problems, or I’ll avoid adding a terminal strip to save on wire but minimize testing or change possibilities, or I’ll leave a switch machine near a joist where I can’t easily get to it. It’s ok in moderation, and it helps me make progress on the bigger task of building and completing the model railroad I want to build. I’ve been describing technical debt for our tools as us not trying to make future-us suffer too much, but acknowledging that some of our choices will make future-us suffer a little bit. “In ten years, we want to be laughing about the short-cuts we took and the pain it caused, not crying about a shortcut that kept us from meeting our real goals.”

That’s not a bad rule for the model railroad, too. As I was cutting in a new circuit for some LED lights for the lower deck, I wasn’t perfectly happy with how I was routing the wires, but I wanted to get everything completed and back together again tonight because keeping everything running is also a good engineering goal. And with luck, I won’t remember tonight’s short cut; if I do, I’m certain I’ll be laughing about the short cut in a few years once all the fluorescent lights are replaced by LEDs.