Quality
The society which scorns excellence in plumbing as a humble activity and tolerates shoddiness in philosophy because it is an exalted activity will have neither good plumbing nor good philosophy: neither its pipes nor its theories will hold water.
-John W. Gardner
Quality is important in plumbing, philosophy, and coding all the same. Bad code sets the foundation for product failure just as bad plumbing does for pipe bursts. If the plumber or coder doesn’t recognize the need for quality or lacks the skill to strive toward and achieve it, the resulting creations will always be flawed and potentially harmful, either to the creators or consumers of those products. Quality is not something you sprinkle on top of your product once it’s done; you must start with quality ideas, quality designs, quality people and quality code.
Design
“Design in code?” you say. Yes, because the back end should be just as pretty as the front. For every misplaced line of code, every improperly named method, and every disorganized module there is a price to pay. The price is hardly ever immediately apparent, as developers are often blinded by the motivation to “get it done, whatever it takes” rather than thinking about how best to do it. The price still takes its toll, though usually much later, and it does so with amplified cost and sometimes detrimental consequences.
Six months into your product cycle, when a big release is looming, the careless “one-offs” and hacks employed by the hasty can derail an entire division while the already overworked engineers track down some real nasty bugs and uncover poor architecture built upon assumptions put into place by hacks. The universe may be glued together by one-off Perl scripts1, but the only companies that allow such mayhem are those obsessed with short-term timing to the detriment of any long-term strategy. Greed and shortsightedness don’t affect some people, but I wouldn’t be caught working for one of those backwards beasts.
The mark of a truly revolutionary product has always been derived not only from its function, but also from its design. When engineers were designing the iPod or the Ferrari F430, design was a core concern placed right alongside engineering calculations and detailed schematics. If Ferrari engineers realize that they need to add a larger fuel pump, they don’t unscrew the old one, jam the new one into the same space and hope it’ll work out for the best. Every change affects the big picture and the big picture is consulted for every change. They go back to the drawing board and figure out exactly what the change affects, where it will best fit, and then test their design tirelessly, stopping nowhere short of perfection.
Now you might say, “perfection in design is an elusive goal and isn’t one that profit-driven businesses should be concerned with anyway”. Well you’d be wrong. First, perfection in design isn’t an absolute, but rather an acceptable threshold that is set by the product’s team and architects. Second, profit-driven businesses should be concerned with design insofar as it is a direct expression of the quality of their product to their customers. Seen in that light, it’s obvious that quality design has an enormous impact on the bottom line. This knowledge of quality in design is one of the primary reasons that companies like Google, Apple and Toyota enjoy incredible success and are known for their great products and happy customers. Design matters; even in code.
Action
Of course all of this translates directly into business action that must be taken. First, all developers must be educated and made fully aware of the entire development process, understanding the reasons for quality and how specifically to strive toward it in their daily work. Next, developers must be made accountable for their work and contributions to the shared code base — code reviews are extremely helpful for maintaining a high level of quality and catching bugs before they cause larger problems. Lastly, the products that the team creates should be tested in a real world environment.
Great developers are developers who take it upon themselves to stay up to date with new and important changes in the industry that could affect the development process. Each developer should know what the current best practices are in each field and the reasons behind them. Every decision that each developer makes will affect the overall product, so a team should do as much as possible to ensure that every one of those decisions is made by a highly educated and skilled developer with good reasons backed up by experience and evidence. These criteria act as a great guide when hiring new developers as well. How passionate is the candidate? How engaged in a specialty is the candidate? No specialty? Why? Don’t know? Red flag.
Accountability is a sensitive subject for many developers because of at least one faulty assumption or stigma in the industry: the idea that writing buggy code makes you a poor developer. There are mountains of literature on this subject, but somehow it still exists as superstition. It is nearly impossible to write completely bug-free code, especially on tight deadlines in a fast-paced business environment. Once this fact is accepted and everyone agrees that bugs will emerge in everyone’s code, this subject can be treated much more rationally. On the one hand you want developers to take ownership of their code so you don’t have random half-written modules being checked in because Bob doesn’t care; but on the other hand it’s a good thing to develop a peer review system that establishes a pattern in which bugs are caught and sanity is kept.
Finally, a user-level quality assurance phase should exist for every product. That is: some non-developer should test the system for usability, consistency and correctness from a user’s point of view. Ferrari will not release a car into production which hasn’t first been driven by several test drivers and Apple won’t release a new iPod design without market and usability tests. In order to carry quality all the way through the development process and into the hands of the user, you must make sure that there is someone bridging that final gap outside of the organization and the inherent savvy into the realm of novice exploration.
There are surely many methodologies that can be employed to ensure high levels of product quality and thus successful business, but this is a reasonable core that should be embraced by every development team.
- Munroe, Randall. xkcd: Lisp. Last accessed 21 Sep 2007. ↩