Accepting the glue…

Back of an Märklin α to C track adapter

Unsurprisingly, I’m increasingly an old guy at work, telling stories about the computing of yore. Still, if I think about what changed in my approach to things as an engineer, I would say that with time I accept the glue.

What does that mean? Like many, I learnt to build stuff with lego, but also the model railway. These things are built out of pieces you can assemble in varying ways, and once you are done, you can disassemble them and rebuild something new. The individual blocks are pretty generic but follow some geometric system which you quickly internalise.

In the university, I learnt about software engineering, writing modular code, but also object oriented programming, with inheritance, class hierarchies, the whole thing. In the shadow, there were darker subjects, typically explained by assistants, like how do you hook things up together, access the system from within that fancy language, something that used to be normal when I was hacking away on my Commodore 64. The world was moving to preemptive multi-tasking and memory protection, isolation was the key, not connecting things.

Unsurprisingly, production code involves a lot of glue, code that just converts and adapts data from one format to another while doing little or no computation. This code feels useless. There is always a good soul who wants to write a generic framework or language to handle these conversions, more often than not, this results in some abominations, who remembers XSLT?

The one thing I learnt is that this glue code needs to be as simple as possible, and checked regularly, as the two things that it connects evolve, the solution is often to add glue layers to connect the old glue without looking at the whole thing, so glue gets layered and no transformation language will fix that issue, it might make the situation worse as the that language is probably opaque.

Recently, I have been watching restoration videos on YouTube (I really recommend my mechanics) and the way things get restored is generally the same: all the pieces are separated, cleaned, fixed and polished and then reassembled. You would assume that elements fixed with screws would be easier to disassemble and re-assemble, but screws rust, their threading gets broken. So more often that not, they need to be forced out and replaced, not much differently from rivets.

I saw a similar pattern when people restore old computers, like the Commodore 64. Some electric components are soldered in place, other are socketed. You would think that the sockets would help the maintenance, they don’t, as they increase the number of contact points that can fail instead of just solder joints that break, there is a solder joint and and connector that can rust. Often the restoration involves changing the sockets. Electrolytic capacitors are the component that absolutely needs to be changed as they leak acid, they are never socketed.

In some cases, the reason the solder joints break is because they support a connector, who creates more stress than a cable. In others the connectors need to be changed because the device will be connected to different circuitry: power supplies get lost, video interfaces change. In many restaurations, the whole Radio-Frequency modulator (the thing that allowed you to connect a computer to the antenna of your TV), is removed, as television over radio-waves is dead.

Sometimes the traces on the motherboard are damaged and bodge wires need to be added. In the end, the solution is always the same: remove the glue that holds stuff in place, clean everything, oil or repaint as needed and reassemble, using whatever gluing method. Sometimes the case is broken and needs to be fixed with epoxy, sometimes the new interfaces need new holes in the case.

Basically, making things modular and maintainable implies that you have a good idea of future failure modes and usages. As the saying goes, It is difficult to make predictions, especially about the future, so more often than not, replaceable components, object oriented code and layers of abstraction end up making your system more complex and thus more failure prone and not that easier to maintain. Even if the engineers had a glimpse of the future, the vast majority of the product does not get repaired or upgraded.

The moment I started doing model-railroading again, one of the first things I did was questioning the modules, i.e. the track elements, cutting them with a Dremel and assembling them in new ways with solder and hot glue. The rails are still modular, but there are new modules, and assembling parts of broken track elements is a good way to make new, non broken elements.

I recently brought back to life a cheap locomotive from the 70s, it now runs on a different power-pick up system (Märklin 3 rails instead 2 rails), with a power and control system, a different type of motor and there are now LED lights where there could have been light-bulbs. The shell of the locomotive could be opened with clips, other parts with screws, the motor was designed so that you could replace the charcoal contacts. When I got the locomotive, the shell had been glued shut (because it opened too easily, I suspect), and I did not replace the charcoals, changing the whole motor instead. The clip for the shell used again, as I strengthened the frame, the screws are mostly still around for aesthetic reasons, the real stuff is glued in different places.

When building things, it is more gratifying to believe your are building the core of the system, that your part must be maintainable. When I maintain system, I generally wish they were more standard and better documented…

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.