I recently had a problem with a leaky pipe. No, I didn’t need to go and see the doctor: this was the waste water pipe in my kitchen.
I’m not sure how plumbing works in all other countries, but here in the UK you basically get 3 options, in ascending order of cost:
- Plastic pipes that are welded together using a solvent. This is the cheapest option to put in, but cannot be separated once done and is difficult to repair.
- Plastic pipes with push-fit connectors. These connectors have an O-ring to seal them, they are fairly cheap and maintainable, but all of the pipes need to be exactly the correct size. OK if you’ve used them from the start, but not interchangeable with the welded type.
- Plastic pipes and compression-fit connectors. These connectors have a conical washer that compresses as the joint is tightened, so they can accommodate both widths of pipe above. Most expensive to manufacture.
Guess which of these was fitted in my kitchen? Of course, the first one. Now that’s not a problem if you never have to take your system apart, or if no defect is found in the original fitting. Unfortunately, the weld in the pipe had come apart somehow after 9 years of service. Maybe it was never done right in the first place. However, I could not repair the joint without easily replacing the entire waste from my sink through to the outside.
If these has been push fittings and a seal had gone, I could have replaced the faulty fitting in 2 minutes and it would have been all good.
However, I ended up replacing half of the waste with a combination of (2) and (3) above: push-fit pipes from the sink to ground level and a compression fitting to graft this onto the slightly larger bore pipe to the outside.
What’s this doing on a software blog, you may be asking.
Pretty obvious really. We have all been accused at some time or other of “over-engineering” solutions precisely because we have designed in the fittings (interfaces) where software systems are designed to come apart so that, at a later date, maintenance can be carried out.
Software maintenance is a poorly understood concept, and it’s really hard to adequately capture maintainability requirements in any meaningful way. Often you have to rely on experience, a combination of business domain experience to anticipate requirements that may change of features that may be added later, and the technical experience to know which patterns and interfaces will be required later. As with all things maintenance-related, making savings on a small upfront cost can result in many times that cost later.
Unfortunately humans are very short-term in their thinking. A project manager tasked with delivering a system but not maintaining may very well favour the small savings upfront as they won’t be left to deal with the maintenance later. And anyway, they’ve delivered a system that meets the requirements right?
It’s different when you’re the one who’s got to go back in and fix the thing later, when it’s leaking gunge all over the place and the management are panicking, because now you’ve got an operational incident. In fact, I’d go so far as to say that you can help to train better developers by making them do the following:
- Sit with users that are using their software, and gain direct feedback
- Fix bugs, both their own and from others
- Be on hand when their features go live to deal with any issues
- Work on production incidents when they happen
- Upgrade or add features to other people’s software
Working through this list should give developers a sense of humility, and maybe just enough experience to understand that next time they have a blank sheet of paper they should anticipate how their software can be taken apart for servicing.
Coming up next: Software lessons from engine oil changes. (Only joking.)
