Brian looks outside software development and notes that the kinds of solutions that work are not the kinds typically employed in software development companies.
I’ve become convinced that the approach to quality taken by most companies, especially large companies, is misguided and based on a flawed model. This use of the wrong model explains why so many companies are having such trouble increasing the quality of the software they deliver.
To explore the various models available let’s look at some other businesses and see how they deal with quality issues.
If your local town has an issue with bad traffic behavior, that can be seen as a quality issue—one with potentially life-threatening consequences. The approaches available to solve traffic problems are basically structural and enforcement. Structural solutions are such things as adding speed bumps or turn lanes. Enforcement is adding more police patrols or radar traps.
Structural solutions are appealing because they work. You simply cannot drive very fast on a road with speed bumps. In the software world structural solutions to quality are things like Code Coverage or code style checks that run automatically as part of the check-in or build process. You simply cannot check-in or build code that violates the structural standard. The downside of structural solutions is that they do not change underlying attitudes.
Software enforcement models are things like after-the-fact code inspections or Failure Review Boards (FRB). Both are focused on determining why an error occurred rather than on preventing it from happening in the first place.
OK, now shift gears to another venue: your child’s sports team (or music or dance lessons—the point is the same). Although some bowling alleys have gutter guards that prevent a ball from rolling into the gutter, in general you’ll rarely run into structural solutions in these venues. You can’t really build a ball that can’t be dropped and you can’t structurally prevent a dancer from dancing “wrong.”
So, that leaves enforcement. To improve your child’s Little League performance do you hire more umpires? At your child’s piano class do you hire someone to blow a whistle whenever they play the wrong note? Of course not: you hire a coach or a teacher.
This is a laughably obvious conclusion in these venues but most software companies have lost sight of it.
We expect our engineers to write better code but by and large we give them no training in how to do so. Most professions have rigorous continuing education requirements. Doctors, lawyers, psychologists, dental hygienists, and teachers all must take a certain number of classes per year to maintain their standing as professionals. Yet in our field there is no such requirement.
This is both a top-down and a bottom-up problem. Most engineers don’t ask for training and most managers don’t suggest it. Ask yourself: does your company include continuing education in its appraisal of your performance at review time? Does your company offer classes in Refactoring, Test Driven Development, Agile Methodology or Code Inspection? If they don’t, they are making a statement that they do not value software quality. They’re not aware that they’re making that statement but they’re making it nonetheless. Shifting to personal responsibility, do you as an individual contributor believe it’s your manager’s job to assure your future employability? It’s not—the only person responsible for your future employability is you. If your company doesn’t make ongoing education a priority that doesn’t mean that you can’t.
Be assured that the next time you interview for a job you will be asked, “So how have you maintained and enhanced your skills?” If you say you haven’t, the interview will be over.
It’s time for a sea change in how we get to quality. Enforcement alone doesn’t work, we need to combine it with training. Companies need to offer it, managers need to recommend it, and engineers need to ask for it.
Brian Tarbox is a Distinguished Member of Technical Staff at Motorola where he designs server side solutions in the Video On Demand space. He writes a blog on the intersection of software design, cognition, and Tai Chi at briantarbox.blogspot.com.