People have been automating software development, testing, and deployment processes since the stone age of software. The toolsmith of today shares a lot in common with these ancestral automation efforts. In this week's column, Danny Faught details how toolsmiths can learn by studying the computer subcultures of the past and present that are similar to their own.
People have been automating software development, testing, and deployment processes since the stone age of software. The toolsmith of today shares a lot in common with these ancestral automation efforts. In this week's column, Danny Faught details how toolsmiths can learn by studying the computer subcultures of the past and present that are similar to their own.
Many of the skills that I use in my toolsmith work fit in one of these three categories-open source software, UNIX programming, and hacking. These are tightly interwoven subcultures that helped shaped the computer technology of today and will affect its evolution into the future. Here's why I think having an understanding of each of these subcultures can help you.
1. Open Source Software
Among the toolsmiths I know, the ones who are familiar with more than a handful of tools have all used open source tools. The open source attitude inspires me to share my tools with others, then I benefit from the feedback and improvements they give to me.
But the open source culture taught me more than that. In "The Cathedral and the Bazaar," Eric Raymond said "Every good work of software starts by scratching a developer's personal itch," which is a good description of how many toolsmith's efforts begin. Raymond also recounted this open source sentiment: "Good programmers know what to write. Great ones know what to rewrite (and reuse)." This embodies the toolsmith's effort to not reinvent the wheel and to make a "build vs. buy" decision when appropriate.
2. UNIX Programming
I'm not talking about the operating system I'm using, but my style of programming. Whether I work on Windows, Mac OS, or Linux, I always use the tricks I learned on UNIX.
I didn't learn my first command line interface on UNIX, but UNIX gave me a way to supercharge the command line. The UNIX toolbox paradigm indicates that tools should do one thing and do it well. The more complex a tool gets, the less opportunity you have to combine its features with other tools in unique ways. If command line tools read from the standard input and write to the standard output, they give the user the power to connect the plumbing between them. Graphical interfaces often don't have this kind of flexibility.
The UNIX programming style is also a good way to achieve portability with a scripting language. Many aspects of languages like Perl and Ruby are built around a UNIX programming model, which can be are portable to a wide variety of operating systems. Toolsmiths often leverage their work by using one of these portable languages to build a single tool for all the operating systems they support.
See the article "A Look at Command Line Utilities" to learn more.
3. Hacking
The hacker culture is at the root of both the open source movement and UNIX. The part of the Jargon File definition of "hacker" that best applies to toolsmiths is "One who enjoys the intellectual challenge of creatively overcoming or circumventing limitations." Toolsmithing is all about getting rid of limitations-so we can speed up our work, do things more often, and do things that would otherwise be unfeasible. Give a hacker a real challenge, and she'll fervently attack it until conquering it.
Another thing I learned from the hacker culture is how to ask questions effectively. If you only ask questions that can't be answered easily with a Google search and take the time to give enough information for the question to make sense, you'll be much more likely to get a good answer, and you'll build a reputation as someone who is worth listening to (see "How To Ask Questions The Smart Way"). This skill enables toolsmiths to get help from other toolsmiths for difficult problems.
As Paul Graham says in Great Hackers, "Good hackers find it unbearable to use bad tools."
Fitting It Together
Eric Raymond's "Hacking and Refactoring" essay inspired me to write this article; his essay really brought these ideas together for me. Raymond relates the three categories I discussed above to the agile community. He said his reaction to reading Martin Fowler's description of the agile refactoring process as an alternative to doing up-front design was: "Dude, you've just described hacking!" I had the same reaction when I thought about how toolsmiths operate. Toolsmithing, when done well, is hacking at its best!
If toolsmithing has similar roots as agile development, does this mean toolsmithing is inherently agile? No, they're not the same kind of thing. Even though I've used the term "agile automation" to describe what toolsmiths do, that causes too much confusion, because toolsmiths can do what they do on any project-agile or otherwise. I think "tool-assisted testing," or "development automation" is a better description of the kinds of support toolsmiths offer.
The closest analog to toolsmiths I can find in the hacker culture is system administrators. Part of a system administrator's job is writing small tools, either for herself or someone else, and deploying open source and commercial tools. The toolsmith does these things, but with a more specialized user base.
What To Do Next?
To become a well-rounded toolsmith, I recommend that you explore the three topics outlined above. Each of these communities has decades of learning to offer us.
Use open source software, hang out with other people who use the same open source tools, and contribute to the source code. Learn the UNIX command line environment- if you're running Windows, first install the free Cygwin package. A large majority of open source tools were built first in a UNIX environment. For the tools that were ported to a native Windows environment, you'll find it easier to use these tools if you understand how they're built in UNIX. And study the hacker culture-no, not the ones with malicious intent who you hear about in the news, but the majority of hackers who have good intentions. There are several references below to get you started.
Are there things that system administrators and toolsmiths can learn from each other? I'm just starting to explore this idea, and I'm curious to hear your ideas.
Further Reading
- The Cathedral and the Bazaar
- A Look at Command Line Utilities
- The Jargon File
- How to Ask Questions the Smart Way
- Great Hackers
- Hacking and Refactoring
- Cygwin
Danny thanks Matt Doar and Grig Gheorghiu for their help with this article.
