Real-World Scenarios, Episode 1: Changecause

The folks at Changecause were good enough to publish a blog post about their efforts to make bug reporting easier for people outside their team. It was a clever solution for gathering issues from end-users, but there are also a few trade-offs at work. GForge satisfies the same requirements in a much more elegant (and supportable) way.

Third-Party Integration, Squared

The first anti-pattern is integrating two third-party tools to each other. Yes, it’s neat, and it’s fun, and I’ve done it, too. Heck, github has dozens of third-party integrations – so cool. But what happens when one endpoint changes its behavior, its API signature, or just goes away? Who do you get help from?

Hey kid, where’s the trouble?

It’s trivially easy to get caught by a problem like this. In fact, I’d say it’s inevitable. And it’s outside your control. At my last job, this happened to us three times in about six months, with some A-list players.

You may be paying (probably too much !) for your task-management tool, in which case at least you will have a defined service level – that is, someone you’re paying to help you out when things don’t work. But most small and medium-size software shops rely primarily on free tools, which usually means you’re on your own. Even if you have an SLA with both (or all) involved vendors, it is extremely likely that they won’t agree on the source of the problem, or its solution.

The Core Competency Question

One of the reasons that these ad-hoc integrations happen in the first place is that it’s software, which is probably your personal core competency anyway. You spend an hour building something, and it works. You get a good amount of value out of a minimal amount of your time, and you exercise some control over your otherwise frantic and unpredictable startup experience.

Except that this integration is not your company’s core competency. Neither is bug tracking, or version control, or DBMS, or any of the other foundational tools that you use to build, e.g., Changecause. So that hour you spent may have saved some other hours of distraction, handling complaint emails, but it didn’t add a new feature to your actual product. And, over the next couple of weeks you’ll spend another eight hours tinkering with the integration to add a field, to handle an API change, or to update the API key again. At that point, you may still be breaking even but it’s clearly not a big win.

Edit: While waiting for my other GForgers to give me their feedback, I happened across this pretty relevant blog post. I’ve bookmarked it for yet another blog post in the future.

Okay, Smarty Pants

…how would you do it with GForge, then? I thought you’d never ask.

I would build that same bug submission form in your website, instead of embedding the Google Doc form. Gather and validate the data using your existing web app framework, like you’re doing for the rest of your app (instead of a different technology, with a different set of quirks and bugs). Then I’d pack it all up on your back-end server, and send an email to your GForge project.

GForge has really good integration with email. You can create a bug/ticket/suggestion or whatever you want via email, by sending to the right email address. By default, it’s [projectname]-[trackername]@[gforgehost], e.g., gforge-support@gforge.com. You can even customize the email address, e.g. support@gforge.com, which is what we do for customer support. Customers can just send us an email to start a support request, and the GForge Support Tracker captures the entire conversation, including attachments (like screen shots, logs, etc.).

It’s still a minor diversion from your core competency. But at least it’s a direct connection between your own technology (which you’re responsible for, anyway) and GForge, which we support every day, for some of the biggest companies in the world. If you want to tweak the form, ask another question (or allow a screen shot), go for it – GForge will still capture everything you send in the e-mail, just the way you sent it.

If you’d like to try it out for yourself, start a free project at gforge.com, or visit gforgegroup.com to download the installer and run it on your own server. If you’re trying it out and have questions or comments, let us know!

Thanks,

PS – I also enjoyed another blog posting by Changecause, this one about their internal planning/task workflow. It’s somewhat similar to where we’re going internally, and has inspired me to build a GForge template. I’ll post an update about it sometime soon.