In the short-lived but mostly entertaining Aaron Sorkin TV Show The Newsroom, there’s a scene where the station manager explains how the team was able to do a good job reporting the news. “You know how?” he says, “We just decided to.”
It’s a spot-on line because “deciding to” is so very often the first step in a chain of inevitability that leads to success. And this applies directly to creating good, well-written software. The techniques are not mysterious. While computing is a relatively young field, the research goes back decades, telling us how create to software with the fewest defects, highest performance, and best maintainability.
We know all about requirements gathering, collaborative programming, unit testing, documentation writing. But before any of that can happen, software quality must be a high priority at an organizational level. And you have to make it so during all phases of a project – hiring, budgeting, planning, mid-course corrections, maintenance.
I start the list with budget and scheduling, but these are tricky and unintuitive. What seems like a trade-off is really not. When you sacrifice quality for speed or cheapness, you end up with none of the above. The time and cost you seem to save during the planning and initial development come back with a vengeance during the debugging and maintenance stages.
You’ve read that before, and you probably believe it, even though it may go against the “software as a commodity” conventional wisdom. But you still have to decide to hire the best talent. Decide to implement code reviews; or pair programming; or formal code inspections. Decide to keep your boss’s boss’s impatience at bay while the planning stage plays itself out.
Decide to follow best practices when designing your interfaces. Decide to research prior art so you don’t (badly) reinvent the wheel. Decide to unit test. Decide to document your requirements, code, and practices.
Once you make the one decision to prioritize quality, the rest of the “decide to”s fall into place naturally.
Because you decided to read computing classics like Code Complete or the Mythical Man Month (or the many other well-known books). Because you studied the Software Engineering Body of Knowledge. Because you care. You made it a priority. Or if you don’t have the time or background for those books and techniques, you found somebody who does and put him or her in technical charge.
Then one day, when your product is done better, cheaper, and faster; when it’s easier to maintain; when your team is happy and someone asks how you did it, you can do your best Sam Waterston impression and say, “We just decided to.”
