Quality Is Job #1
Ford may have stopped using that tag-line over 20 years ago, but it’s still relevant. Quality is more than building something that usually works or ‘meets requirements’. It’s more than that. It’s something that not only works when things are perfect, but degrades gracefully and in a controlled manner when things aren’t. It’s not just done according to spec, it’s something the user thinks is done. It’s something that provides more value than cost. It’s something that delights. And it applies at every level. From the RFC describing what you’re building, to the entire SDVP ecosystem, quality stands out. You can rely on it. Does it cost more? Very often it does, but it provides even more value.
Quality is stable and reliable. As of last week, grep is 45 years old. Yet we still use it every day and you
never wonder if it missed something. You might wonder if you got your regex correct, but you know grep did its
job correctly. Yes, it’s been updated and new features have been added, but someone who used it 45 years ago would
still be comfortable using it today. That’s quality. Similarly, the Douglas
DC-3/C-47/Gooney Bird. First flown in 1936, with production
ending in 1945, there are still over 1000 flying today. If you bought one you certainly got your money’s
worth.
So how does that relate to us? Simple, and it goes back to Ford’s tag-line. Quality isn’t something you bolt on later. It’s something you build in. From the use cases to requirements to implementation to operationalizing and support. Regardless of your function, role, title, or part of the product life cycle you work on, quality is job
