"You're a software guy and you're writing about RX7 Maintenance on your site! You shouldn't do that."
That's an almost fair assessment. First, I'm more than a 'software guy'. It's my site, I do as I wish, SEO rules be damned. But it's deeper than that. It's really about quality and while this might not make sense to some of you it's my site and I get to explain.
Once upon a time at a company whose name starts with a big red H, a younger version of me had to deal with different departments regarding some software I had inherited and I got into lots of discussions and arguments with people in Software Quality Assurance, Software Configuration Management and Software Test. One day, David R., the head of Software Quality Assurance, were just talking. He told me that his favorite book was Zen and the Art of Motorcycle Maintenance: An Inquiry into Values
He said, "Quality isn't a bunch of requirements you meet. It's a feeling you get from knowing."
No, he wasn't a hippie. David was in the know.
Really, that's what it is. You can do statistical process control like Six Sigma, you can certify software through the SEI levels, you can do all of that. All of that gives you data to rationalize a feeling. With anything mechanical the feelings are easier to come by because quality is tangible. You can see it, feel it and know it all without a bunch of statistical process control.
Quality is about paying attention.
When your car or motorcycle does anything different, you investigate. It can be the odd sound, a different smell, a sudden pull to the left on the highway or a sudden drop in mileage. The more data you have, the more you can support that feeling. With a motorcycle or, in my case, an RX7, that knowing - understanding what is going on with a vehicle at any point in time - lends itself to expectations, and those expectations are what one would consider formal requirements in software development.
Quality is iterative. What passes for quality today may not pass for quality tomorrow. That sound you fixed yesterday may reveal a new sound you didn't hear the day before. You may fix one thing to find another needs fixing; this is the whack-a-mole of quality.
Quality is a habit. On complex projects, be it fiddling with a carburetor or dealing with object oriented code, documentation is a means of assuring quality through deepening understanding of what is happening so that in a few days you can go back and see what happened.
Quality is indefinite in every sense of the term. Quality has to be constantly re-evaluated in different contexts.
Quality is about knowing and part of knowing is knowledge. You can have a lot of knowledge and know nothing. Knowing is a bidirectional relationship with knowledge
There are those of us that develop relationships with the concept of quality. As someone who deals with abstractions, dealing with more tangible things is a relaxation and allows the pursuit of quality to be more easily rewarded.
Sure, I write about maintaining my car on my site. But it's about knowing. It's about quality. If you don't understand why information like that belongs on the site of someone who deals with software as an architect, developer, project manager and consultant... maybe you don't understand software as much as you should.
Maintenance is maintenance is maintenance. Exercising those muscles constantly builds stronger muscles.
