Like most consultants, I don’t see many projects below a certain size: from a few weeks to a few years of developers’ and project managers’ time, and costing certainly tens and likely hundreds of thousands of dollars. To justify that kind of investment, the project has to either be solving a big problem, or at a big company, or most likely both. My role in such projects is often that of the “toolsmith”, and I spend a lot of my time thinking about how to support these big undertakings: what can I build to help a team of highly skilled developers, working on a complex and evolving project for months or years, make the most of their time? It’s an engaging question, and I doubt I’ll ever stop thinking or writing about it, but it’s also a frustrating one, because it leaves so many people and so many projects behind.
Recently, I’ve started paying much closer attention to the “other half” of software development: the small applications built (or half-built) by users, not developers, in small businesses or small departments; the specialized timesheets, customer databases, todo lists, shift schedules, project charts, contact lists, issue trackers; the millions of one-off tools for managing highly specific data for a highly specific market, evolved in place by the people who use them. These are the applications that consultants never see, because even one day of a consultant’s time would be more than the application was worth or the company could afford. Joe Kraus calls this the long tail of software, Clay Shirky calls such software situated, but most people at most companies just call it Excel. Yes, some people might use Access or FileMaker or more exotic tools like wikis, but the overwhelming majority of such applications start life, and often end it, as spreadsheets.
It was, in fact, the dominance of the spreadsheet in this application area that got me interested in it in the first place. The problem is, the spreadsheet’s really a pretty lousy tool for the job. As someone obsessed by software tools, it was incredibly painful, but also incredibly interesting, for me to watch people time after time use this hammer from their office suite to try to cut wood. It’s such a common occurence that I’ve taken to describing this whole class of applications as things that are spreadsheets and shouldn’t be. The spreadsheet users know this, but they don’t know what to do about it. They hate the pervasive duplication, the awkward collaboration, the simplistic searching and filtering, and everything else that makes the spreadsheet a wonderful tool for accounting but a bad one for data management, but they use it anyway. Why? When I ask them, they have a question for me in return: ok, wiseguy, what should I be using instead?
It turns out to not be such an easy question to answer. And it is, in essence, that question that this blog will be devoted to: if they shouldn’t be spreadsheets, what should they be?