Home > Anti-Inspiration, Debunking The Magic Tool, Media > The perils of ‘easy’ tools – Basecamp

The perils of ‘easy’ tools – Basecamp

September 10th, 2010

When you use a commercial fee-for-service provider, you will typically get service in direct proportion to your cost. When you use a free one, you get what you pay for and boy do you pay.

Now, those costs you need to assess are not just the objective costs of the service in dollars. It’s subjective cost relative to the value and importance of a service as a means of achieving a goal in the context of your other costs. You don’t hire the kid down the block to mow Fenway Park after school. You don’t hire I.M. Pei to design the toolshed you’re going to make with stuff you pick up at Home Depot next weekend.

One personal favorite example to pick on is: Basecamp and I pick on them in the context of using Basecamp as a project management tool for running web projects. For all I know, Basecamp is perfect to manage your Badger husbandry operation. I just don’t know.

Semi-Disclaimer: I have participated in projects that have used Basecamp but have never led one using it. My participation spanned the “asses the progress when called in to be Winston Wolf (Link is NSFW) and fix a Charlie Fox (also NSFW)” to just having a looksee and contributing one deliverable of many.

Now, I will admit to picking on Basecamp in part because I have had it pitched to me very badly several times. If you want to convince me a tool is right for a job, it’s important to be ready to make a cogent case for it.

The pitches I’ve gotten  have spanned these two extremes:

A very smart, content sensitive producer and overall exceptionally capable but somewhat technically naive person who was managing a project with many different stakeholders who’d been backed into Basecamp before it could really be thought through.

The other pitch from somebody who project managed by front-loading with brainstorms and went off the rails when it came to executing on time and on budget. The sort who whiled away his time in constant exploration of new tools to manage a project as a way to avoid actually taking responsibility for managing it. You know the type. One of those guys the technical staff secretly works around to make things suck less entirely out of their own dedication to the ineffable geek holy grail of ‘elegance’. The sort the team complain about but can’t go on record with complaint because the ‘upstart young innovator’ has the bosses ear? The one who you have to un-teach his bad habits from new people? Not the guy who can be a hard-case but the guy who just checks out. The one who’s never there at 1AM in a crisis, or, if he is there at the crunch, doesn’t know enough to shut up and go get pizza. The one who books a speaking engagement to overlap your launch date. You know THAT guy.

Since the last time somebody tried to be ‘that guy’ to me about Basecamp, it’s been improved some. http://37signals.com/security and http://basecamphq.com/help/general#exporting_data are both better now  but still, you are parking what could be client-sensitive data on somebody else’s server(s). You’re not able to run your own Basecamp instance to see and manipulate that exported XML.

You’re still left with (I hope) having to decide what is and isn’t appropriate to put into Basecamp from a legal and confidentiality perspective given that you don’t really control the environment and you’d be left rolling your own tools to get use from whatever you got in the XML you exported if you chose to leave Basecamp or if you want to review the specifics of the project a year from now when Basecamp has changed or might not even exist.  You can’t keep an archive of the configuration environment and the software to review the data later. Oh, and you still can’t download all your files at once and the built in version control mechanisms are scanty at best and, arguably, broken. Appending a letter to a file name is not version control unto itself.

In both cases pitched above the concerns were trumped by the “but it’s easy” argument. In the case of the first guy, the project was ultimately, mostly, successful. In the second case, Basecamp was hardly to blame for the FUBAR’d results. Easy’s good. I love easy. Easy usually comes at a price and, for some members of a team, easy is relative.

So? What’s wrong with Basecamp?

If you have a project with sensitive data, or one with signifiant business stakes, how smart is it to put your core communications in the hands of a company that, at maximum, is charging you $150 a month? No single customer is worth enough to them to do more than say if you have a problem “You can also submit a support request via email. We’ll get back to you within a few hours.” No phone support.

How smart is it to build a workflow, a whole communications infrastructure, around a toolset somebody else can decide to modify, to ‘improve’, in the middle of your project in a way that may undo some quirk you’ve come to rely on?

In the case of software project management, and a website, almost no matter how small, is a software project, there are so many aspects of project management that are outside the scope of what Basecamp offers. Issue tracking, documentation, time and billing, client approvals, rights management.. and so on.. and so on…  Now there are add-on products and some set up specifically to integrate with Basecamp. But 37signals themselves have this to say about that:

"Note: These apps and integrations are not endorsed or tested by 37signals. 37signals does not assume responsibility or liability for any issues caused by the use of third party products."

So, if you decide to put the core of your project’s operation in the hands of a provider who will promise to respond to you ‘in a few hours’ is that fast enough for you?  Is it wise to rely on a provider who offers the tool you’ll lock all the central planning information into but insists they host the application, you have to ask yourself;  Is ‘less easy’ perhaps a better idea?

Remember, whether outsourced or in-house, you’ll need to host your site, a staging/dev server, and probably a project wiki and file services (See below, for why you’d likely do at least some file hosting in-house and not only via Basecamp) and, of course, the applications your site needs on a server (Apache, MySQL, Joomla, whatever.)

Now, the host I use has, at least, 24/7 live chat and yeah, they’re cheap but also not nearly as ‘turn-key’ for use as a host for Project Management tools as Basecamp is (heck, they’re not as easy to use for anything as Basecamp is they provide services to at least nominally technical people). A hostisng provider like DreamHost don’t claim to be doing more than foundational I.T. services. There are lots of tools they do easily host that are useful for project management and, with a technical staff, you can host whatever you like (if it runs on Linux or BSD) if you pay more for dedicated hosting.   This is the host you can migrate everything from in a day and come right back up as if nothing went wrong when they tick you off.  37signals is the other host you have to pay  to host the swoopy project management system. You could choose hosting one of these (or something else) at the hosting provider you already have to pay for anyway or you can go with Basecamp .

(When I need to host a project where there’s real money at stake? I’ve used these guys:http://www.rackspace.com/index.php I can tell you from direct personal experience, there’s a human being who will bust their buts an 800 number away 24/7/365.)

Basecamp and hosting and configuring your other tools are  costs in addition to the omphaloskeptical (thanks for the word B.D.) ruminations your Project Manager will go through setting up your instance of Basecamp. That’s in addition to the money (time)  you’ll spend with the technical and social integration you’ll need to do to include Basecamp in the suite of tools you’ll use. So, cost is already becoming a subjective and complicated value.

Managing a software project demands dealing with people of a variety of personalities, disciplines and expertise. The tools they’ll gravitate to are going to differ depending on who they are and, in some cases, the tools are so tuned to their particular field you would be hamstringing them if you deprived them of those tools.

Some examples:

  • A graphic designer working on a web project is going to do most of their work an image editor (or several). Depending on your connection, the practicalities of uploading (and downloading to review) and managing versions of files that can be multi-hundred-megabytes in size when you have to up and download to a server not on your LAN can get ugly. Fast.  Even for a project running hosting those files on Basecamp you’ve still got to have to track progress in these files in parallel with descriptive information about their status entered in Basecamp. Meanwhile, you’re running a workflow on a file server (even if that File server is Basecamp because you have connectivity to do it) to track who’s working on what, where it is  and, ideally, with self documenting metadata in the multi-layered files themselves. You’re already ‘outside of Basecamp’ for a significant aspect of communication between team members and you should be.
  • Developers? They like version control. To say they like version control is the understatement of the century. The good ones are addicted to it like crack. There are LOTS of challenges in how one implements version control for a web site since the end product, as a whole, often doesn’t have a ‘build’ associated with it. Individual components don’t have milestones that necessarily track the project’s milestones as a whole on any level a general Project Manager would likely track them. Basecamp is not SVN. You’re going to need some mechanism of version control for the developers. Maybe it’s come sort of CVS-like thing on a dev server or even their own desktop(s). Maybe it’s a combination of landmark versions of the whole site for project milestones on a staging server and multiple version control repositories for the different components different members of the team are working on.  You’re going to need to have this process defined and, to at least some extent, internally documented. Again, that part happens outside of Basecamp.

(One day we can talk about a case where I hamstrung coders by depriving them of good version control. They were much less hamstrung or deprived than they thought but my mistakes there are a story for another day.)

  • Next, we have legal. Throughout any web project of substantial size, your lawyers or your company’s legal department will be reviewing rights agreements, contract terms, engagements with clients around the dreaded payment points and conditions of approval. You may have sample data for your project you need to protect on your own or your client/partner’s LAN for legal reasons. There are all sorts of scenarios where the access controls for aspects of a project necessitate not hosting things, or tracking them, at Basecamp. So, again, you’re running part of the project outside of Basecamp.
  • So you have video? The kinds of things you need to track to produce video from the high end where you have studio, grip truck, camera, audio, talent and other staff to manage to the low end where you just have a few tens of gigabytes of raw footage from DV to cut together are distinct from how you’d set up Basecamp for the rest of the web project. The ‘lingua franca’ of managing video production, while, in this example, part of the web project, is not the same as that for managing, for example, MySQL and PHP development. All that happens outside of Basecamp. (Ok, yeah, you could run a separate project in Basecamp to manage the video production but, in that case, for many projects, the reality is that most of the team won’t be accustomed to working virtually via collaboration software and are, often, in and out for the day. The people you have to manage on shoot day(s)? The freelancers? Those are gonna be hearing from you while you hold your clipboard. So, umm, why bother doing it online? Collaboration in preparation? Sure, maybe. Fair point.  But, again, you’ll have duplicated tracking and meetings to work out the details. Meetings with people who won’t be participating in the collaborative Basecamp workflow unless you wanna cover them for more than their day rate.)
  • There can be writers, third party evaluators or auditors, executives above the ‘in the trenches’ team,that are reacting to and working off what they see on your staging, development/test and production servers. All things that, depending on your project would need to be tracked outside of Basecamp.

Now, all the examples I’ve cited mean the Project Manager would need to track the milestones, to-dos and deadlines and readiness of deliverable or incremental versions for elements you can’t natively watch and manage or effectively communicate necessary details about within Basecamp. You’re gonna be havin’ some meetings.

Some of you will immediately jump up and down and say “But that’s what Basecamp is FOR you blathering idiot!” but what’s lost in that instinctive reaction is the overhead involved. Not just for the Project Manager but for everyone else on the team.

For everyone else on the team, Basecamp is additive to their workload if they are to report both within the tools and workflows of their department/disciplines and to the central Basecamp tracking under the direction of the Project Manager.

Sure, you could have a super-heroine of a Project Manager gather it all and be the one doing the data entry in Basecamp.  She can take good notes at meetings, be a disciplined like a Shao-Lin monk about looking in on the Wiki, the Dev sever, the source repository, the uploads of roughcuts to the video server, the file server where the designers stash the graphics and be sure it’s all captured in Basecamp but then all she’s doing with her time is living her life as translator to Basecamp-ese.

  • Fine when you have a huge team.
  • Fine when you can afford a super-heroine of a Project Manager (if you can even find her even in this economy).
  • Fine when the people responsible for all the legs of the project are doing a good job maintaining their own documentation of their progress so well she can just look in and check and not call another meeting.
  • Fine when you have the infrastucture to give the: Designers a file server, the developers a version control server. The video editors disc (or time to export and encode) space for review cuts and so on.
  • Fine when, despite all this, somebody, other than the Project Manager herself, needs to have a thirty thousand foot view of the project’s timeline, deliverables and dependencies on a regular basis and you can afford to have that tracked, with the multiple layers of duplication described above.

(Oh, about that 30 thousand foot view you can get when you use Basecamp?  A lot of Project Managers think a Gantt chart is a good way to get a thirty thousand foot view of a project but:  “At this time we don’t have plans to add this sort of feature to Basecamp. Sorry about that.” )

What it comes down to is this, if your project is large enough to need the super-heroine Project Manager, you need a lot more resources than even a $150/month Basecamp subscription provides  You have to ask yourself, if she really wants Basecamp and not some other collection of tools and procedures she has honed to a razor edge successfully managing her projects then, perhaps, just perhaps, she’s that guy.

Now, the next obvious question is: “But Jon you bloviating bombastic bafoon! I have a team of 2 people and I am just making a little Flash game! Why can’t I use Basecamp?” Well, sure use Basecamp but then, if you spend a lot of time setting it up, maintaining the project and ensuring you get the most from that ‘oh so pretty’ user experience you might wanna ask yourself. “Am I that guy?”

All this said, I’m sure there are countless cases where Basecamp really does help highly capable people do a better and more convenient job managing their projects. I am not saying “Don’t use it.” I am not saying “It sucks”. I am just saying, don’t let the use of Basecamp let cause or encourage you to be “That Guy.

Oh, and here’s another reason I pick on them: http://37signals.com/svn/posts/1066-web-designers-should-do-their-own-htmlcss?139

And here is somebody else’s NSFW but solid rant on why that’s utterly inane: $%& 37signals and their bourgeois bull$%^

Post to Twitter Post to Facebook

Comments are closed.