Editor’s Note: This post was originally published on Seattle 2.0, and imported to GeekWire as part of our acquisition of Seattle 2.0 and its archival content. For more background, see this post.
By Anthony Stevens
I remember reading a Fast Company article a few years ago that explored software quality assurance activities within NASA.
Quoting:
What’s going on here is the kind of nuts-and-bolts work that defines the drive for group perfection — a drive that is aggressively intolerant of ego-driven hotshots. In the shuttle group’s culture, there are no superstar programmers. The whole approach to developing software is intentionally designed not to rely on any particular person.
And the culture is equally intolerant of creativity, the individual coding flourishes and styles that are the signature of the all-night software world. “People ask, doesn’t this process stifle creativity? You have to do exactly what the manual says, and you’ve got someone looking over your shoulder,” says Keller. “The answer is, yes, the process does stifle creativity.”
It’s a bureaucratic, officious, overwhelmingly boring way to develop software. But for the task at hand – launching tons of metal and rocket fuel into orbit, with living people aboard (oh, and returning them safely home) – it works.
Startups live in a completely different world – a completely different universe – than these NASA programmers. Quickness, agility, and passion are paramount. Tech chops are required, yes, but on any top-ten list of adjectives describing the best startups’ software, “bug free” probably won’t make the list.
Should it?
How concerned should startups be with quality? It’s a knotty question. I’ve known startups whose stated intent was to have their users do their QA for them. They figure that they’ll get multiple chances to convince customers to use their product, bugs be damned. That’s a risky proposition. Some customers may be turned off by what they see that they won’t come back. Joel Spolsky wrote about the “crappy 1.0” phenomenon a few years ago, and it’s worth a re-read.
I can’t deny that most of the pressures facing startups all point in the direction of reduced software quality. However, I also don’t think it’s a either-or decision. I’d like to propose that software quality can be viewed as something that can be increased at the same time as increasing speed, agility, feature count, and all these other wonderful things that startups want to achieve, and not only that, but actually CAUSE those things to happen.
So, having said all that as a preamble, what sorts of quality initiatives should you be considering that will help your startup release more high-quality code, quicker and with greater agility?
Get Lots Of Users. Despite the misgivings I stated above about forcing your users to do QA, the fact is that all bugs are shallow.
Implement Continuous Integration. Whatever your precise definition of Continuous Integration is – do it. You’ll find bugs more quickly, have more confidence when pivoting, and deploy with less risk.
Implement Source Control. As I’ve written before, this should be a no-brainer. But…
Write Unit Tests. This one is very controversial, especially in the context of the “fast startup” argument. Some people are firmly convinced that every extra line of unit test code is a line of feature code that is left wanting. However – I firmly believe that in addition to the traditional benefit of unit tests, which is providing a platform to conduct automated regression tests of your changing codebase, unit tests also increase the quality of your design by requiring developers to think in terms of small, granular, easy-to-change pieces that can be independently verified and, when bolted together, result in some very elegant architectures. Think of unit testing as “baking in quality from the start.” The result – faster, more confident pivoting, and zero throwaway garbage.
Simplify. I wrote about this a couple weeks ago here on Seattle 2.0. The fact is that complexity, by itself, can cause quality problems. Complex things break, mostly in unexpected ways.
Pick Your Experiments Carefully. The Simplicity argument has a close cousin: new things break. Avoid new, exciting, experimental, unproven tools and technologies if you can get away with a tried-and-true replacement. Carefully manage your exposure, to allow you to focus your time and concentration on your own product, and not fixing bugs in somebody’s new compiler, version-control system, or AJAX doodad.
Last, but not least:
Hire Good People. Software development is still a nascent enough engineering discipline that people make an outsized contribution to the success or failure of the product. Good developers make far fewer mistakes – big and little – than poor developers. Maybe a couple of orders of magnitude fewer. That’s huge for startups. Would you rather be fixing crappy code at 3 AM, or implementing new features that will raise your revenues 10x in the next calendar year? Your choices for your co-founder, partners, or key technical hires may make the difference.
