Maintenance-Driven Development

LG

Loren Goodman

12/17/2018

One of my coworkers has a motorcycle which he frequently complains about and sometimes gets to ride. Earlier today he was lamenting how long it has taken to repair what should be a simple issue with the clutch. Now his motorcycle is not some custom-built creation or a finely tuned race bike. It is your standard assembly line product that has thousands of identical siblings. A standardized modern machine with easy access to interchangeable parts that should have a fairly predictable set of maintenance problems and known resolutions.

This is not the case here. His bike has been in and out of the shop for months while they struggle to diagnose and repair the problem. The last fix only lasted a dozen blocks before the clutch went out again. He has lost a good chunk of the summer’s opportunities due to his bike being in the shop. My first thought was that his repair shop does not know what they are doing or maybe they were just milking the situation. I was wrong – so wrong that it inspired this post.

It turns out that the shop is one of the highest-rated motorcycle repair shops in the Chicagoland area and furthermore, the shop is eating the cost of the additional repairs. The owner of the shop repairs 800 to 900 bikes a year. Out of that many bikes, this bike was in the top four worst cases they’ve had. Fixing what was wrong was not the problem; the problem was diagnosing what was wrong, made nearly impossible by the way the bike was designed and assembled. The parts are all soldered together, each seal must maintain pressure; and because of this, no seal can be tested individually to see if something is broken. It is impossible to test any join without breaking that seal and bleeding the system, which can put the entire system at risk.

Then my friend said something that really hit home “this bike’s design was driven by performance and comfort; when those guys were putting it together, that is what they were thinking of.” He then added: “It was just not designed for maintenance” – Designed for maintenance… what does that mean to a motorcycle designer? A software engineer? I’ve never thought about the mindset of a motorcycle designer before; in what ways is that engineer the same and different from a software engineer? What are their driving goals, how do they define success? Are the phrases: “Parts can be replaced” and”Code can be patched” the same in their mind?

When something is wrong with this specific bike model, the avenues for diagnosis and insight come with a very high transaction cost and even more risk. Even if the problem is determined, the fix is not a straightforward replacement of a single part or adjusting some valve. The interconnected nature of the bike makes targeted repairs virtually impossible and unnecessarily complex.

When I was a kid, I assembled my own dirt bike by buying various parts from garage sales and other BMX friends.We rode over a lot of messy terrain and my bike would frequently get a flat tire. To repair it:

  • I took the tire off (< 2 minutes),
  • held the inner tube under water to find the bubbles (< 2 minutes),
  • put a patch on it (< 2 minutes) and
  • put it back onto the bike (< 2 minutes).

Of the dozens of times I patched the inner-tube, there was never a time where it continued to leak once patched.I basically KNEW it would take me eight or fewer minutes to fix a flat and getup and running. If my friends were waiting in my driveway to go riding and my bike had a flat, I could say with very high confidence, give me 8 minutes and I will be ready to go. My bike had predictable maintenance and (fortunately) they were willing to wait the 8 minutes.

Now suppose that when it was initially put together the manufacturer had reduced weight and assembly time by gluing the tire to the rim and welding all the parts together instead of using bolts. If that were the case, taking the inner-tube out would require cutting the tire off the rim and cutting the rim to get it off the bike. What are my options if I cannot get my hands on the inner-tube without damaging it? What do I tell my waiting friends? “Give me an hour to fill up my kid swimming pool so I can submerse the entire bike to find the leak”. And even if I found the leak, I can’t fix it without welding the rim back together. At the end of the day, given the number of flats I’ve had over the years, I would have spent far more time and energy fixing my bike than could ever have been saved for the employee putting it together. What are the odds that one day it would be too much hassle and the next flat would end my bike-riding forever?

Bringing the conversation back to enterprise software; how does designing for maintenance fit into the modern enterprise development process? What does it mean? Is it still important at project schedule crunch time? Should it be? Longer-term considerations generally take a back seat to “just getting it working” when timelines are tight.

Gluing things together is much faster than taking the time to plan out how it should be bolted together. Some of those trade offs are clear and others are judgment calls. Knowing when to stop worrying about future maintenance is as essential as knowing that it needs to be considered. If that pendulum swings too far in either direction the result is generally a great deal more expensive in the end.

To clarify: maintenance is *not* swatting bugs. In my mind, maintenance is about what might need to change in the future; e.g. changing out what no longer works for something that does in an efficient, consistent and predicable way whether it is a business rule, a clutch, or a bike tire. There is a science and an art to designing for new sales. There is a science and an art to keeping users relying on your product year after year. And part of that is designing for maintenance.