Over the past few years, I've noticed a troubling trend among digital humanities projects: too many are left incomplete, mouldering as vaporware in a code repository somewhere, waiting for funding, time, and people. Other projects finish, but never find enough users to fulfill their promise. And yet others finish, find users, sometimes even popularity, but are hard to extend, change, or adapt for a more general purpose. We can trace these different types of failure to a few easily avoidable problems in the initial stages of the projects. In the hopes of helping my fellow HASTACers (and everyone else) get started on the right foot, I present here some advice for aspiring tool-makers. I will also show, in a later post, how easy it can be to build a useful tool out of existing open source software with no programming involved. But, before we get into the details of creating something, let me lay out some principles that should guide every digital humanist.
1. Ask many questions. First ask, what do I wish were out there already? Look around, and if theres nothing available, you may have an idea for a new tool. What is there a need for? What do other people find hard or inefficient to do now? What can you do quickly? The success of the NEH's recent One Week-One Tool initiative is instructive in this regard. If you start out overly amibitious, it could take years to see any results, if ever. The funding cycle for larger projects is quite slow and you will likely be unable to devote full-time work to your pet project. This is not to discourage grand ambitions, but to encourage everyone to look for the low-hanging fruit, too. Once you've identifed a potential problem you can solve, start researching existing tools, projects, and platforms. This leads to my next point:
2. Don't reinvent the wheel. This is, by far, the biggest problem I've seen. Rather than spend time researching what work others have already done that can solve some, many, or even all of the identified problems, the interested parties--no doubt excited by their ideas and eager to get building--plow forward using whatever technologies they know best, whether it be Ruby on Rails, Perl, PHP, etc. There are, however, many, many underpublicized yet useful, mature, and stable open source projects out there. Given the number of people across the globe working on similar issues, it is highly likely that there's someone else already farther along in at least one aspect of any need you can identify. Use their work. It's far better, for efficiency and maintainability, to mash together as many existing, stable, actively maintained projects as you can. If you can get away with doing no coding at all, yet still create an innovative, useful tool, you win. One of the cardinal virtues of programmers and systems adminstrators is laziness. Learn from them and don't do things yourself when someone else has already done it for you.
3. Do your research. You can't avoid reinventing the wheel if you dont slow down at the start of the project and do your research. Nobody would think of diving into writing an article or a book without first researching the relevant literature for months or even years, yet many have no qualms about assuming nobody has done work relevant to their digital project. Just because you haven't heard of anything doesn't mean it's not out there. Rather than worry about details of implementation, first do diligent research. Because of the decentralized nature of the digital community and the still extant disciplinary lines, many times you won't hear about a project that fits perfectly with your own work unless you spend a lot of time actively looking.
4. Find good collaborators. So, you've identified a need that isn't already filled, found out what work has already been done on your problem, and may even have a sense of what technologies you're going to use. If you haven't already, look for collaborators or, at the very least, people to ask some tough questions about what you're doing. Just as you would with your written scholarly work, find knowledgeable people to bounce your ideas off, people who will help revise, reshape, and refocus your work. If you've settled on a project that you can't easily pull off on your own, or that will require some custom code, find a programmer. If you don't already know how to code, don't try to learn on the clock. You will build something that may work, but it will be brittle and impossible to change, extend, or even maintain. There exists a mature (and continually evolving) set of best practices in the IT industry that you must use if you want to ensure your project of a long life. If you're doing something with metadata, for example, talk to people in the Library/Information Sciences department. You won't even know what you don't know until you start collaborating.
5. Think generally. You have probably settled on a problem specific to your field or period. Don't let that keep you from considering how what you're building might be used by others in other disciplines. If you don't start with a desire to make something generally useful, you'll lock yourself into choices that make it hard or almost impossible to reengineer your tool later into something everyone can use. Again, an expert coder (if you need custom code) or a technical expert of some sort is invaluable here. You want to reach as broad an audience as possible. The worst position you can be in at the end of your initial development is to discover others who want to use your tool, but can't because it doesn't quite fit their needs.
With these points in mind, you will set yourself up for success and, I hope, be able to contribute something to the community that we'll all find useful. These points are, of course, not exhaustive; if you have your own advice to aspiring tool builders, please comment. In a future post, I'm going to give a crash course in building an application without doing any coding using the powerful, but somewhat complex Drupal software.