Developing in the Wake: How APIs Should Work

We have been using Basecamp, the online project management software for a few weeks now. Basecamp offers a straight-forward interface and set of tools for project management and collaboration. To do lists, milestones, and file sharing allow us to easily keep tabs on what we’re doing in our office and involve partners and occasionally the remote employee. Basecamp is working out well for us, but this isn’t an advertisement for that product. Instead, this is an advertisement for a particular approach to software development.

What We Get with Basecamp

We use Basecamp for our day-today task management within the web team – creating new projects, assigning tasks and attaching discussions to those tasks, sharing small documents, and creating milestones. I can quickly find out what is on my plate, what deadlines are coming up, or what Dave and Jon are currently working on. It’s accessible from just about anywhere and is dead simple. Without a doubt, the service has increased our efficiency.

What We Don’t Get with Basecamp

One of the tasks that we typically grumble about here at NUAMPS is having to produce weekly reports. Every Friday at 5pm, all NUAMPS employees shoot an email to our manager with a Word document containing what we accomplished during the week. During the average week we all move across several projects in a variety of capacities, so keeping track of those tasks and then dropping them into a document at the end of the week is never as small a job as it is meant to be.

The problem was that no matter how hard I tried I could not incorporate that weekly reporting into my daily workflow… because that Word doc didn’t matter – not until late Friday afternoon anyway. But when we began using Basecamp, we were suddenly tracking each task and accomplishment and in many cases our discussions as part of that daily workflow. Suddenly those little actions necessary for reporting became part of the general work routine. We began seeing the benefits in a very real sense through out our workflow,  just not for reporting. In fact, the only area that we didn’t immediately see benefits was in reporting.

Like, I said, Basecamp is dead simple, so simple that it has no built in tools for reporting. At first this annoyed me. I was tracking everything I needed to report but had no way to report it. Then I realized that there are several 3rd party services that offer reporting tools for your Basecamp account. This was encouraging, but all come with an additional cost, and they might not even produce the types of reports we need – end of week completed work by employee.

37 Signals, maker of Basecamp, doesn’t offer a whole lot – no native iPhone app, no native Android app, no reporting tools, no invoicing or time tracking tools. But then I realized that they offer something much better than any of that. They offer a full API. Because 37 Signals chose to not bloat the service with features but instead build a service that can be extended, a small industry has developed in Basecamp’s wake. The Basecamp site currently lists 108 ‘extras’ – services, applications, and tools built using the Basecamp API.

108! And I couldn’t find the right reporting tool for me. So I did what any web developer would do in such a situation. I began to develop in the Basecamp wake. Using the API, I created a reporting tool tailored for our current needs. Because of this open-ended approach – limiting service functionality but offering channels for users to expand the service to fit their needs – this one simple web service has become extremely customized and targeted to our needs.

Developing with Basecamp's API