Tag Archives: maintenance

A stitch in time saves nine

A non-technical description of technical debt

In software engineering, “technical debt” is a feature of an application’s code which makes future changes more difficult.

Technical debt takes many forms, but it can be as simple as methods with misleading names, outdated documentation or large sections of repeated code.

dash_gaugesAs an analogy, imagine that an indicator bulb fails on the dashboard of your car. You buy a new bulb and, pop out to replace the old one. Your spouse warns you that dinner will be ready soon. “Don’t worry,” you say, “it’s only a ten minute job”.

When you climb into the driver’s seat however, you can’t find any way to open the dashboard; in fact there are no screws visible at all. So you open the bonnet and look for suitable screws there. The screen wash reservoir is in the way, so you carefully remove that, but due to the way the pipe is connected, this means spilling all the washer fluid on the ground. Your spouse calls that your dinner is on the table. “Nearly there.” you reply. Now you can see some screws which look like they might release the dashboard, but they’re completely inaccessible. The only way is to get the engine out, so you replace the screen wash reservoir and drive the car around to a friend who has an engine-lifting winch. Luckily it comes out without any nasty surprises and you undo a screw labelled “DB release” – simple!

Inside the car however, the dashboard is not at all released and you notice one of the wipers is hanging loose. You re-attach the wiper and locate the correct screws. Remove EngineFinally, the dashboard opens! But it’s not over yet – the bulb you bought, after consulting the car manual, doesn’t fit. As the car is still in bits you take a taxi to the car dealer who supplies you with the correct bulb. When you vent your frustrations, he explains that the bulb you had was for an earlier model and when the new car was designed they weren’t given time to update the manual. Apparently the dashboard is made of a single piece of solid plastic because that makes manufacturing easier and cheaper. No one ever checked the screws were labelled correctly as the release date was brought forward to compete with a car from another manufacturer. Maintenance costs are usually down to the end user and rarely feature in reviews…

So eventually you get the bulb replaced, the engine back in and take the car home. By now your dinner is not just cold, it has things growing on it and your spouse is threatening divorce.

The car in my analogy has terrible technical debt. The “interest payments” needed to modify or fix it are huge. But in other ways it might still be a good car – good handling and fuel consumption and it’s black, everyone likes black. To anyone who has never opened the bonnet, the car is fine – it works, so what’s the problem?

If the occasional hassle of changing a bulb doesn’t seem like a big deal, bear in mind that software is changed a lot. No sooner is an application released than new features are needed, bugs may be discovered or perhaps an external system changes that requires the application to change to keep up. A code file is created once, but will likely be changed hundreds or thousands of times over the lifetime of the application. Most of these changes are not anticipated from the outset and the cost of making them can be dramatically affected by how well-designed, well-documented and testable the code is.

Sometimes code is made well in the first place – that takes an upfront investment of time. Sometimes existing code is improved to be more maintainable – the time to improve it is like paying off the debt. In either case the investment saves time down the line.

There is more on writing maintainable software here. For a deeper look at technical debt, read Martin Fowler’s piece.

Something creaking on the bike

While I’m riding, one of the main ways I know my bike is running ok is by the noise, or lack of it. As I often ride in quiet places, I’ve become used to the normal sounds of the gears and tires on the road and I’m acutely aware of any other rattles, clunks or, in this case, creaks. This is good because I tend to notice problems early. The downside is that I can be driven crazy by a leaf in the mudguard which probably isn’t slowing me down much.

The creak started a few months ago and was occasional, mostly when climbing. I managed to live with it until recently when it became more persistent. It definitely came from the front of the bike and could be recreated when stopped by leaning on one end of the bars then the other.

Lennard Zinn’s website has a long list of problems which fit this description, some much scarier, and more expensive, than others. At first I thought it was the headset or stem, so tried adjusting these, a bit tighter, then a bit looser. No change to the squeak. I inspected the titanium head tube and carbon/aluminium fork for signs of damage, but they looked fine to my inexpert eye.


Then I looked further down at the One23 QR skewer. I loosened it right off to the point that the wheel would drop out if I lifted the front of the bike. Pushing on the ends of the bars was now silent. Looking closer I noticed that the plastic bearing surface on the skewer closure was badly worn. It had large grooves in it, probably from the last few months of winter grit and maybe closing it too tightly sometimes. I was fairly confident that it wouldn’t be unsafe to ride with. There was no chance of the wheel coming out, but the creaking was reason enough to replace the skewers.

Of course, it’s a bit pathetic that a pair of £23 skewers would wear out within a year, even when ridden many miles on mucky roads.

To replace them I got some Hope skewers with a brass bearing surface. This, or an enclosed cam is far more reliable in the long term as I discovered from recent internet research. Had I known this, I never would have bought the One23 plastic ones. Still, lesson learnt. The Hope skewers are more than twice the weight mainly due to having a stainless steel rod rather than titanium, but the difference is still less than 100g – a few sips of water.


The noise seems to have gone, but I won’t know for sure until I climb a few hills.

Lately I’m tending towards kit which is low maintenance and built to last rather than cheap and lightweight. This is partly for the long term financial and environmental cost, but mostly because I don’t want the hassle. I prefer riding to tweaking.

EDIT: It turned out I was wrong. The creaking continued for all of my 600km ride. I did manage to get used to it, but I was annoyed not to have fixed it. Interestingly, it was actually more persistent than before. Secondly the noise disappeared completely when I rode in a torrential downpour on a different ride. This suggests that it is a two moving surfaces problem rather than anything internal/serious. As suggested here, I’ve just picked the plastic coasting off the fork dropouts and can’t recreate the sound, but that was the case last time. I’ll update again when I’ve taken the bike out for another ride.

EDIT 2 : OK, I really think it’s fixed now. It wasn’t the plastic coating on the dropouts, but the mudguard stays attachment, which was butting up against the skewers. Presumably this was moving very slightly when pedalling hard and causing the creak. Noticing this I moved the plastic eyelet to the other side of the dropout, so it’s now inside the fork. The downside is that the plastic eyelet slightly rubbed on the edge of the rotating hub – not great for an efficient ride, but trimming a little plastic off them seemed to solve this.

mudguard-clamp-side mudguard-hub-side