In my first real technology job, a friend taught me two important rules:
- If you’re going to go through a process more than once, build a tool and automate it.
- You’ll never do anything just once.
That said, for many of us (particularly non-developers) there’s a substantial cost to building that tool. I’m not so good with Perl or Ruby or Visual Basic and often I’d find that the tool that took me so long to build didn’t really meet my needs. If I were a better toolsmith, I could just build one to throw away, learn from my mistakes, and build a second that’s better. Instead had to postpone the building, struggle with the manual process, and hope to use that struggle to really suss out the requirements for automation.
I think that organizations are in a similar situation: they’re often encumbered by too many manual processes and in need of better tools. But just like individuals, before you start building the tool it pays to know if you’re a good toolsmith. Organizations with those skills know to build their first version quickly, try it out, throw it away, and try again, learning from their mistakes. Most organizations, like most of us, are bad at building their tools. IT projects come in late and frequently don’t meet users needs. Does that sound like you? Don’t jump to build the tool, but take your time, pay attention to the manual process, and really understand what you’re trying to do.
(On reread, you could just think of the manual process as a first draft for people and organizations that aren’t good at developing software tools.)
