Here's Part Two of Jody's talk at Dreamit Ventures. Check out some of the other posts in the series. Wouldn't you like to know more about The Heartbreak of Technical Debt?
I was a quality chemist before I became a developer. When I came into development, I was shocked that there was so little emphasis on quality because in drug manufacturing everything is about quality.
In the world of quality, there are two main terms that you hear: Quality Assurance, or QA, and Quality Control, or QC. In software, we usually talk about QA, and that’s about ensuring quality throughout the entire process. When I was a chemist in the lab, my senior labmate might say, "Oh, look at your glassware, it's not clean enough." That was part of quality assurance. When someone says to you, "This code needs commenting," or, "We need to improve this and refactor that," that's all quality assurance. It happens throughout the process, and typically in the form of peer review.
Quality control is more like what they do at a factory at stages of the assembly line, where they say, "Oh, this screw's the wrong length. I'm going to throw it out." It's more like a pass-fail. You measure what you made and if it doesn't cut muster, then you throw out the whole batch.
Quality control is reactive. You're measuring after the build to make sure the quality is present. Quality assurance is proactive. It's washing your hands before you cook dinner rather as opposed to testing for bacteria when it's on the plate. Quality control is necessary, but it's typically more expensive to fix a problem at that stage rather than to avoid problems through quality assurance. For that reason, increased quality assurance is almost always a good investment. For example, if you were building houses, you couldn't afford to say at the end of the project, "Well, this one's no good. I'm going to throw it out." If there were problems, like the beams were crooked, and you checked it at the end of the process in quality control, then it’s too late to fix. The whole roof is on it now. The only way you can build something complex well is with quality assurance, not with just quality control. It's too complex to check it all at once at the end and then try to fix all the bugs.
We do have quality control in software processes. In enterprise work it's often called UAT, or User Acceptance Testing, where the customer will tell you pass or fail for each feature that you've developed. What's more important most of the time and why you usually hear about QA is because in these complex systems the only way you can really achieve quality is by focusing on it throughout the entire process. It's not something you can just add on at the end.
Continue to Part 3 of this series, Good for the Code and Good for the Coder