Zen and the Art of Software Maintenance

I hate this sentiment so, so much.

Let's take it out of the realm of software for a moment. Let's use the motorcycle metaphor, since this is a ZATAOMM thread.

At the end of the day, the customer does not care if, for example, you fixed their bike sloppyily, quickly, or haphazardly; as long as it works. It is the craftsman in us that makes us care about the nature of our work. It is something we ultimately do for ourselves.

Bullshit!

It is true that no customer is going to care how we organize our tools in the mechanics garage. We should not be having long arguments about whether 2 storage cabinets or one make more sense for holding our screwdrivers. If at the end of the day, the radiator is replaced in the same way, and the coolant is cycling correctly, then both the slow and steady and the quick and haphazard mechanics did a good job, however they accomplished this fact.

But the ENTIRE POINT of the book, is that these two mechanics WILL NOT accomplish the same job. Sure, they may both deliver the same result in 7 out of every 10 jobs they are given, but those last 3 matter! And are almost certainly going to be the hardest of the 10.

More direct to your point, however, customers ABSOLUTELY DO care whether we replace the radiator with a cheap chinese knockoff that's likely to break in 1k miles, or the 5x more expensive overseas german version. And they ABSOLUTELY do care if the haphazard mechanic or the slow thoughtful tedious one does the job.

They just don't all care equally. Some customers want the cheap chinese knockoff (the giant if-then conditional). If it doesn't work, they'll just throw away the bike and buy a new one. Other customers want the german and thoughtful mechanic, and will pay accordingly.

Its about knowing who your client is and why.

I recommend you investigate plumbing. Yeah, seriously.... I have not done anything very complicated, but it takes much of the same mindset (or skillset), it is satisfying, and you will have a job for life (aka I have just hit 50 and sort-of age discrimination (or just can't deal with the nonsense anymore-ness - or everything is so familiar it is so tedious))

As the customer (or rather, as the maintenance programmer at the end so one of the customers) of your software, I very much care. As a requirements provider for the actual users, I also care and they do as well.

Your giant if-then conditional "works", but is not sustainable or maintainable. It is fragile and poor quality. Quality matters.

I once got to speak with a materials engineer who had the task of trying to discover why a drone aircraft (ostensibly made the same way as always) was suddenly failing very frequently. This was, essentially, a one-off product. They had one customer, and built the drone from off-the-shelf components. The system was driven by a basic two-stroke engine, it accomplished what was needed. This worked for years, until it didn't. It turned out that the maker of the engine (which included the drive shaft) had changed their source (from the US to another country, but that change itself is unimportant). What was important was that while it was the same (weight, power, fuel consumption, etc.) engine, the manufacturing of the steel components was different. They had different qualities and the new one had a tendency to fracture due to the low quality steel (this took quite a bit of analysis to identify since the aircraft were, well, crashing and breaking apart).

This quality (the quality of the steel) was not in the customer specs. They didn't think about it, it "just worked". Until it did matter, the aircraft were failing at higher rates than anticipated (driving up costs and losing out on the utility of the aircraft). The drone manufacturer was also risking losing this contract, which was quite lucrative to them, since the MTBF for their product was now below their promised thresholds.

If you don't pay attention to these qualities, you'll end up like them. You'll have a "working" product that suddenly fails and drives you out of business, or otherwise diminishes you. Or, if you're the engineer or programmer, you'll give your customers a poor quality product that doesn't actually work for them, it only seems to. Until it doesn't, because you gave them a fragile piece of shit.

Don't be the problem.

At then end of the day, a great many people, firms, and governments are finding that they care about the increasingly fragile set of design, engineering, and control kludges Boeing have had to strap on to the 737 airframe in order to 1) accommodate the initial low-clearance landing-gear design (intended to facilitate cargo handling), conflicting with 2) greater demands for efficiency through 3) ever larger ducted-fan engines 4) mounted ever further forward, and higher, on the wing resulting in 5) AoA control issues under high-throttle conditions answered by 6) a pilot control defeat countermeasure which has resulted in multiple crashes and the loss of over 300 souls.

The customer doesn't care about the implications of design decisions, until they do. Clean, simple, stable, predictable, maintainable, modifiable designs deliver quality performance over a longer period of time. Complex, kludgy, unstable, unpredictable, tightly-coupled, unmaintainable designs will eventually bite you in the ass, or scatter your body parts over the landscape.

The fact that the implications aren't clearly discernable in advance does not mean that they do not matter.

And yet, even after seeing firsthand that computer programming is "extraordinarily similar" to the work of a vehicle mechanic, you still refer to it as "software engineering".

Do we think it has anything in common with engineering? Why not call your work something like "software mechanic" or "software artisan"? What is with the continued need for programmers to try to aspire to engineering, while not actually being licensed engineers or practicing engineering?

I don't think anyone outside the field takes programmers any more seriously when they call themselves "software engineers". Software overall is still late, slow, hard to use, buggy, and insecure. Nobody's fooling anyone.