My K-12 experience included classes in both woodworking and metal crafting. Of the two, I most benefitted from wood shop. My wood shop teacher didn’t stop at explaining the correct way to hammer, saw or turn wood: in addition, he fed us a steady stream of adages as we worked wood - Measure twice but cut once. If you can't find the time to do it properly, how will you find the time to fix it? You can do it quickly or you can do it right. - and infused an ethos that embraced quality and competency as well.
Software developers are constantly criticized for sloppy coding practices. System and network administrators are similarly castigated for configuration errors. While the root causes of some of these criticisms includes unrealistic benchmarks, increasingly minimalist quality assurance efforts by vendors, or a desire by “everyone” to publish at Internet pace, it’s quite possible that software development could be improved and deployments better secured if the tech community were to infuse a similar ethos of quality and competency to hacking code and managing hosts.
The tech community focuses on “how to” and expects that practioners learn ethics, patience, and care for its crafts along the way. Many artisan- or master-quality craftspersons are born through the current method but not nearly enough. By adapting certain axioms that helped me and my wood shop classmates to, “not just make do but make fine”, perhaps the tech community can affect positive changes in how it develops, deploys, uses and enjoys fine software.
Some axioms that might cross over well from wood shop to hacking code or administering hosts include:
Measure twice cut once
CWE/SANS tells us that resource mismanagement, insecure interaction between components, and porous defenses are the most common software errors. What would make more sense than to preach to developers, “Review twice, put into production once”? This same advice is probably applicable elsewhere in tech. It’s certainly useful for anyone responsible for configuring a host or security system. Even email users would benefit from reading a URL twice before even bothering to cut-and-paste the URL into a browser. And wouldn’t everyone benefit from “read twice, hit send once”?
Better tools save time; they don't make you a better craftsman
If any adage is more appropriate for how to manage technology today, please share. The desire to publish or produce in Internet time drives us to automate. Recent history offers ample evidence that automation developed or deployed in haste, by individuals who are not craftsmen, generally gets owned. Perhaps tech needs to spend less time developing substitutes for craftsmen, more time developing the craft itself, and return to developing automation when we can be more confident we’ll get it right.
strange how princes and kings,
given a list of rules;
- R. L. Sharpe
Getting it right is a terrific segue for the next axiom.
If you can't find the time to do it properly, how will you find the time to fix it?
Haste to production is a root cause for configuration errors, inclusion of scripts without review, lax patch management and many of the software errors I noted earlier. Perhaps it’s time to empower mid-level managers or developers with the responsibility to challenge impossible deadlines. Before the tech community can do this, however, we need to conduct studies that prove what many infosec professionals believe is true: the cost to restore is commonly greater than the cost to have spent sufficient time to review and test.
Before you laugh, think about why clamps matter in woodworking. They serve as additional arms and legs to hold or secure materials in place. When you build larger or intricate furniture, you will use many clamps. Now, think about infosec: security folks encourage defense in depth, which is similar: you can never have enough $security_measures.
The things I make may be for others, but how I make them is for me
Do you or your organization value quality or pride in product or service workmanship, or is the higher priority getting to market first, quickly, or cheaply? Consider software companies and developers: take pride in your product, preach and practice coding as a craft that has as many nuances – design, documentation security, performance – as crafting a ladder back chair. You have choices: you can hack, or you can be a hack.
The tech community needs to react thoughtfully not impulsively to assertions that the criminals are winning, that we’re losing the war, and that terrorists are in our water systems. We’re not going to mitigate any of these threats by producing generations of digital citizens who develop more secure software or administer hosts securely until we correct the aesthetic.