Bug Tracking

Bug Tracking Work Flow with Git

noreply@blogger.com (Damon) — Fri, 21 Jan 2011 19:24:00 +0000

At TrackJumper, one of our goals is to create bug tracking software that allows teams to work the way they want to while providing the structure that helps keep them organized. It's not always an easy task. The more helpful and specific we get with the features we add, the more TrackJumper becomes "opinionated".

That's why our "priority" field is really a generic "status" field that you can change to suit your needs. It's why we don't encourage any preconceived notions about how you split your project up - we just give you "buckets". You can assign your buckets to users, releases, types of bugs, or anything else you come up with. We use Git, so we create a bucket for each Git branch.

It's simple, but effective. We create a git branch to try out some UI experiments, implement a new feature, or fix a complex bug. As soon as we create that branch in git, we create a corresponding bucket in TrackJumper. When the bucket is empty, we can be pretty sure it's about time to merge it back into the master branch. We then merge, delete the old branch (if appropriate) and it's bucket (if appropriate).

We'd love to hear how you prefer to organize your bugs. Email us at info@trackjumper.com or leave a comment below.

In Defense of Chargify

noreply@blogger.com (Damon) — Tue, 12 Oct 2010 15:35:00 +0000

Chargify, the company who makes a clean and powerful API to help companies with their billing, has just upped their prices - a lot. Gone is the free plan, and in its place a $99/month option. (Also available to small existing customers is a $39/month plan).

When we built TrackJumper, we looked at Chargify. We even implemented it into an early version of the product. In the end, we decided not to use it because Braintree's API got us the basics for free. Not going with Chargify slowed us down, and limits our ability to rapidly change our billing system. But that's a trade-off we were comfortable with, and it's been working for us.

The reactions to the price increase on Hacker News, for example, are pretty much universally negative. Some going as far as to accuse Chargify's leadership of strong arming their customers or just generally not doing "the right thing".

But lets look at this in what I think is a more reasonable light:

Chargify was underpriced.
Chargify has a great product. The intricacies of billing schemes are not trivial to implement and I don't think it's unreasonable to say that using Chargify can save companies thousands of dollars in development cost at a point where cash is likely to be in short supply.

Chargify offers great service.
Customer service is not free - and you want good customer service for your billing system. Chargify was/is offering outstanding customer service. I know this because I had some questions about their Braintree integration. I opened a ticket and the next thing I knew, I received a phone call from their CEO, Lance Walley. We couldn't fix the problem (that Chargify doesn't yet support Braintree's V2 API), but he sure as heck tried to find a solution.

Chargify has been very transparent.
Lance routinely tweets about how many customers Chargify has and what their business is up to. He's all over the customer support tickets. As I said before, he will call you and tell you all about what they're doing if you make the slightest effort to contact them. This leads to the crux of my argument:

You must do your own due diligence.
Spending even a little time investigating Chargify would have told you that they are not making tons of money yet. That their product is free for almost all of their users. That they haven't raised significant amounts of money (at least not publicly). Is it surprising that a new CEO would come in and increase prices in this situation? Of course not. And if you'd checked, it think it's pretty likely that they'd have told you as much. I know I was told exactly that.

If this price increase was a surprise, you weren't paying attention. If your business depends on Chargify, and you can't afford a price increase, shame on you for not doing your homework.

On the other hand...
I'm not going to let them off scott free. Going from zero to $99 per month is a pretty drastic step - especially for businesses who aren't yet profitable. They could probably have done a better job at actively communicating their plans (rather than just telling those those who asked). This transition will cause a lot of cost and problems for their existing customers. Chargify owes it to them to help smooth that transition.

And the list of benefits they touted as they announced the price increase was weak -very, very weak. I'd have preferred that they said, "Hey, we're undercharging for our fantastic product, and we need to focus on our core business, so we're raising prices".

Bottom line - don't overlook Chargify because of a poorly handled transition. There is a bigger picture - look at all of it.

Show the Current Git Branch in Your Unix Prompt

noreply@blogger.com (Damon) — Thu, 07 Oct 2010 16:48:00 +0000

I picked this tip up from Xavier Shay (who happens to be a phenomenal instructor on all things database related). It's a simple function that will save you the hassle of continually typing "git status" to see what branch you're on. I've added a slight modification to keep it quiet when not in a git repo.

Add this code to your .bash_login (or whichever config file it is that you use):

function parse_git_dirty {
  git diff --quiet  2> /dev/null || echo " *"
}
function parse_git_branch {
  git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e "s/* \(.*\)/(\1$(parse_git_dirty))/"
}

export PS1='\[\033[33;40m\]\@ \u@\h: \w$(parse_git_branch)>\[\033[0m\]'

Then restart your terminal and you'll see the name of your curent git branch in parentheses after the path. It even adds a * to show that you're in a "dirty" state.

This

01:27 PM damoncali@macbookpro: ~/apps/ninthyard>

becomes

01:27 PM damoncali@macbookpro: ~/apps/ninthyard(master)>

or this, if you're in a dirty state

01:27 PM damoncali@macbookpro: ~/apps/ninthyard(master *)>

Sometimes it's the little things that make your day.

Using TextMate Syntax Highlighting in your Blogger Blog

noreply@blogger.com (Damon) — Wed, 06 Oct 2010 15:14:00 +0000

When writing about code in your Blogger blog, it's helpful to be able to highlight the syntax to keep things readable. Doing this in CSS is a chore, but luckly, TextMate will do it for you.

Turning

@ideas = Idea.think_something
@ideas.each do |idea|
   idea.build
   idea.try
   if idea.good?
   idea.keep
   else
   idea.trash
   end
end

into

@ideas = Idea.think_something

@ideas.each do |idea|
  idea.build
  idea.try
  if idea.good?
    idea.keep
  else
    idea.trash
  end
end

makes things a little more readable, right?

Here's how to do it. Open a new TextMate file and cut/paste/input the code you want to be in your blog. Make sure you've selected the TextMate theme and syntax highlighting options you want to use. Also make sure you haven't selected any of the text in your file.

Go to Bundles > TextMate > Create HTML From Document

Instantly, TextMate will create a new HTML file, but with automatically generated CSS that matches your TextMate theme. Just cut and paste the entire style tag and its contents and the contents of the body tag (but not the body tags themselves) into your blog post. You'll need to do this with your Blogger editor set to "Edit HTML".

If you'll be writing about code a lot, you might want to cut and paste your TextMate CSS into your Blogger template. Just put tack it onto the existing CSS in your template (go to the "Edit HTML" page on the "Design" tab). That way, you don't need to copy the CSS every time you have some code in your blog.

Track the Source of Goal Completions with Google Analytics

noreply@blogger.com (Damon) — Tue, 05 Oct 2010 15:53:00 +0000

It's perhaps the most basic of questions for a internet based business:

Where are my customers coming from?

So it's a little odd that you can't tell this in Google Analytics without a little (and I mean little) work. Most everyone knows about goals in Google Analytics. You set them up, and a little script to your "goal page" and then every time someone hits that page, Google Analytics records a Goal. For example, you may have a "thank you" page that shows up after someone signs up for your web app. That's your goal page. There are a few more custom options, but that's really the meat of it.

But how do you tell where the users who hit your goal page came from? Thankfully, it's pretty easy.

Once you have a goal set up, click the "Custom Reporting" link in the sidebar:

Then click the "manage custom reports" link, which will take you to a list of your reports (you have none). Click the link in the top right corner labeled "+ Create New Custom Report".

Now you're on the report creation page, which uses a nice drag and drop interface to make reports.

First, find the blue "metric" called "Goal 1 Completions" (or the metric for whichever goal you want to track). Drag it from the sidebar over to the first dashed blue box on the report.

Next, find the green "dimension" labeled "Source"and drag it into the first dashed green box on the report.

Edit the name of the report (there's a link next to the title), and you're done!

The First 1,000 Visitors: Part 1 - Web Application Directories

noreply@blogger.com (Damon) — Thu, 19 Aug 2010 13:44:00 +0000

Many TrackJumper customers are building web applications for one reason or another. Most are businesses, and some of those are run by developers who are scraping the bottom of the bootstrapping barrel trying to get their efforts off the ground.

TrackJumper was born the same way - and we'd like to give back to the web community in the form of knowledge. The first 1,000 visitors can tell you a lot about your web application - your conversion rates, your bounce rates, where you get traffic, and what sorts of visitors are apt to find your offering interesting.

This post is the first in a series in which we'll expose some details about how TrackJumper got it's first 1,000 visitors. We hope you find it helpful.

App Directory Submissions
It's an oldie but a goodie - there are plenty of people on the web who aggregate information about web applications and publish that info for the world to see. These range, of course, from outright spam to legitimate publications with millions of readers.

The best part about these sites is that they're free. The worst part is that submitting your app can take a bit of time, and you may or may not get any traffic out of it. Some of these sites use do-follow links (!), some use nofollows, and some use oddball javascripty redirect schemes - presumably to mess with Google and/or for internal stats tracking.

To ease this burden, here are the application directory sites that sent us at least a small amount of traffic.

The clear winner, Feedmyapp, sent us a significant number of engaged users. In fact, one of our first customers came from this traffic. On top of that, their listing gets a nice do-follow link. Can't complain about that.

KillerStartups also sent a substantial slug of traffic. On the plus side, they wrote up an original (although slightly forced) piece of content about our app. The links are nofollow, so that's a downer.

This site is well put together, and seems to have an enterprise focus. Unfortunately, it's a pain to search, so I'm amazed that it sent any traffic at all. But it did. The link you get out of it redirects to another site first, and that's about all I cared to investigate. I assume it's worthless for SEO.

This is a nice directory of "Web 2.0" apps, and is actually useful for finding apps. Although the traffic it sent was minimal, I'd keep an eye on this one just because it's clearly useful to actual people. Unfortunately, you get no link juice from listio.

AppUseful is another web app directory - similar to, but less polished than listio. We didn't get much traffic, but we did get a do-follow link.

Billed as the "Business Software App Store", which I wish were true. Unfortunately, GetApp provides a weak user experience, no do-follow, and not much traffic.

NetWebApp is your bread and butter web app directory. Nothing fancy, and is easily searchable. Maybe they could use a little more fancy, though, because they didn't send much traffic. Got a good do-follow link out of it, though.

WebBasedSoftware
It's not hard to see why this one sent almost no traffic. Their listings are just one line text descriptions next to a text link (which is a redirect, of course). Needs a little more effort.

The Numbers
Each of these sites sent the majority of their traffic immediately after we submitted our app. All had trailed off to pretty much nothing after a few weeks. What resulted is summarized below:

384 visitors down, 616 to go.

Takeaways
Submitting to these directories will bring you a good bit of interested traffic, and some will give you a nice do-follow link. All are free. At the very least, submit to Feedmmyapp and KillerStartups. They drove a about 300 quality visitors between the two fo them. There is a rapidly diminishing return with these sorts of sites, however, so I wouldn't spend too much time on them.

Did we miss any? What other good free traffic drivers are out there?

Freelancers Need Different Bug Tracking Tools

noreply@blogger.com (Damon) — Fri, 25 Jun 2010 18:37:00 +0000

What's the biggest difference between working as a freelance web developer and working for say, a startup? Both environments tend to involve small teams. Both are very much product oriented. Both are at the mercy of their customers. So although the businesses are quite similar in many ways, there is one difference - in a freelance operation, the customer is involved in building the product - literally.

There's a bid difference between taking a bunch of feedback from UserVoice or GetSatisfaction and having a client tell you exactly where to put that button. The average startup (if there is such a thing) is generally fueled by people who live and breathe technology. Even the marketing guys live in their computers and know the difference between CSS, HTML, and Ruby. As a result, startups can tolerate some complexity in their bug tracking process (although we would suggest that they do not have to!).

That is not necessarily the situation for the freelancer. Have you ever tried to get a client to use Rally? Of course not - it's just not going to happen so you'd be a fool to try. But what are the alternatives? Email is usually what wins. And email, we all know, is where bugs go to die. But we dont' think it has to be this way. There is a way to keep freelancers and their clients working happily and efficiently. There are just some specific requirements.

Simple: This is crucial. A good freelance bug tracking tool should not require training or knowledge of agile processes. It should be intuitive and obvious. "Just give me a place to type the problem in". If it's more complicated than email, guess where the bugs will wind up: in your email.

Separate Projects: Freelancers have lots of projects for lots of clients. They should remain thoroughly separated for obvious reasons. Nobody wants to see other people's bugs mixed in with their own.

Multi-User: Along with those projects come clients. A bug tracker is no good to a freelancer if adding additional user accounts is cost prohibitive. Many bug trackers ramp up their price tag as you add even a few users.

SAAS: A freelancer's time is his or her currency. Every minute you spend working on something else is cutting into your hourly rate, which means you make less money and enjoy less of your time off. If you can find a simple one (good luck!), you can set up and maintain your own open source bug tracking app - you have the skills. But this is a false economy. What do you charge per hour? How much time do you spend on it? What about hosting costs. In the end, there's a reason that there is a a healthy market for bug and issue trackers. They make good financial sense.

Freelancers, don't give up on keeping your projects' bugs organized. It can be done. You just need the right tools. We like to think we've made a good one. Try it for free to find out for yourself.

Simple Bug Tracking with Google Docs

noreply@blogger.com (Damon) — Wed, 23 Jun 2010 16:24:00 +0000

It may seem strange for the maker of a commercial bug tracking tool to be advocating the use of Google Docs for a simple bug tracking solution, but that's what I'm going to do in this post. Don't get me wrong - I don't really believe that Google Docs is the best way to track issues in the long run, but there is a substantial amount of learning that can be gleaned when you start out with the simple spreadsheet.

Bug tracking, first and foremost, is about communication and your team's process. Even if you don't adhere to a structured methodology, you still follow some sort of process. Your process may be "Work on whatever you feel like working on." You might have standup meetings each morning. You might even (gasp) be following an old-school waterfall process.

But whatever the case, you and your team do have a flow to the way you do things. Don't interrupt that flow without a good reason. If it's working, keep doing it.

So when you start out a new project with a new group of people, you'll need to find that flow. It is not the time to enforce rules, but to figure out what works. Every team and project is different. What worked well on the last client project may not work as well on your new internal project. This is true for pretty much everything - including bug tracking.

In the early days, the flexibility of a spreadsheet can be very helpful in finding your team's bug tracking groove. We like Goolge Docs because they're easily sharable and easy to work with, but any multiuser (online) spreadsheet will do the trick.

Start off with a single page with a sinlge column titled "Bugs". If you're used to monstrous bug trackers, you might be surprised how far this can get you.

Pretty soon, you'll want to add more columns. Dates, status, priority. Go ahead add them.

Eventually, you may find you want to group tickets together. Tabs are great for this. Cut and paste is your friend.

Charts? Try a few.

After a week or two, take a break. Stop and evaluate how your team is functioning with your spreadsheet. Some things will be well used and working smoothy. Others, not so much. Is that column for severity really helping? What about those charts you added? Do they give you actionable information or just look pretty? Are you breaking out your tasks in a logical way? Most importantly, does everyone know what they're supposed to be working on? Are your milestones being held, or are they just a date field that gets changed when you run out of time?

At this point, you have some good insight into your team. It's time to break away from the spreadsheet and get something a little more robust. Alas, the flexibility of the spreadsheet is it's downfall. They're also fragile, and every team I've ever been on eventually moved away from them for that reason. They get cluttered and messed up over time.

But since you started with the humble spreadsheet, you now know exactly what to look for when you go shopping for a bug tracker. You know what you need to make the software work for your team, not the other way around.

Incidentally, this is exactly how TrackJumper was developed. We started out with a Google Spreadsheet to track bugs. Once we figured out the best process for managing manage bugs in real life, we turned it into an app. We built in just enough flexibility to cover our experiences without introducing an unnecessary level of complexity. We're pretty proud of the end result, and hope you'll like it too.

Severity or Priority: Stop Making Work For Yourself

noreply@blogger.com (Damon) — Thu, 20 May 2010 02:40:00 +0000

One of the primary motivations that lead to the creation of TrackJumper (which is set to launch in a closed beta as soon as next week) was a simple idea that would guide all of our decisions:

If we ask a user to do something, he or she should get a payback in time, money, quality or satisfaction.

It's stupidly simple, yet it's frighteningly easy it is to find examples of bug trackers that create work for their users without generating additional benefit.

Some of this stuff is entrenched in the history of the software industry. Take for example the concept of rating a bug with a priority and a severity. I don't know where the concept came from, but I imagine someone somewhere created a ticket that was very low in priority but very high in severity:

John: Why is this bug rated as very-low priority? It totally crashes the system.

Alex: Because only 1 in 10,000 users will ever see it.

John: But it CRASHES THE SYSTEM. Are you telling me that's low priority?

Alex: Look, I get that it's serious, but we use priority to help us, well, prioritize what to do next. This one doesn't impact enough people to rise to the top of the list.

John: So, you're telling me that one user that has his entire installation blow up on him would call this a "very low priority". Think of the customers - it's not all about you and your code!

Alex: **groan** Ok, how about this. Lets create another column in the spreadsheet called "Severity". We'll give this one a "very high" severity but a "very low" priority. How's that sound?

John: As long as you get some urgency on this I don't care what you call it. Just don't tell me that something that fails catastrophically is not important.

And the Severity Column is born. It comes from a good place - caring about your customers is good! The trouble is that severity is a totally useless concept. Some might call it a vanity stat. Something that makes you feel like you're getting good, actionable information, but in reality is just sucking time and energy out of your work day.

Does knowing a bug is severe help you decide which one to work on? Yes, but there is more to the story. In the case of John and Alex, Alex correctly understood that even severe bugs that have little impact on the business are low priority. In other words, the severity is baked into the priority. Highlighting it separately does nothing but create confusion, duplicate data, and take extra time to manage.

And that is why TrackJumper tickets don't have a severity field.

Hello, World!

noreply@blogger.com (Damon) — Fri, 30 Apr 2010 14:33:00 +0000

Welcome to Jumping Tracks, the TrackJumper blog. If you're here to read about the ins and outs of software development, you're in the right place.

TrackJumper is a soon to be launched bug and issue tracker designed specifically to meet the needs of small, cross-functional teams working in fast-paced, agile environments.

The desire to build TrackJumper came from experience. Many, many times we've worked on small software development teams. Startups, side projects, client work. In every case, issues piled up - things that we needed to prioritize and remember, but not necessarily something that had to be done right away.

In nearly every case, we tried to use some sort of software to keep on top of things. Our experience goes something like this:

The first stop is Excel. But Excel seems to get worse with each new release, especially on a Mac, and keeping a spreadsheet synced between multiple users is a nightmare. There's too much manual data manipulation. In short, Excel was a total failure. Nobody used it. Surely, Google Docs is the answer?

Nope. Google Docs is better for this sort of thing. At least everyone was using the same document. But we found that the flexibility of the spreadsheet was counterproductive. Each developer tended to "customize" The Spreadsheet with their own notation, formats, and the like. Eventually, it gets chaotic. And you still have the problem of manually manipulating lots of data if you want to gain any insight from it.

No wonder they make specialized bug tracking software. We tried lots of them. I don't know why, but in every case, it seems like we ran into the same problem: complexity. It's like a bunch of developers got together and said, "Since the business guys aren't going to be using this, lets go nuts."

Well, in our experience, the business guys do use it. Agile is the way to go, and if you're doing Agile right, that means keeping your eye on the customer at all times. That, of course, means you want a good business guy around. And you want him working with you, not against you.

But blaming the business guy for not using the complex bug tracker is a cop out. Because developers don't use them either. There is just too much friction in these complex products. You wind up doing extra work to keep your bug tracker happy. Insane.

So the failure of the specialize bug trackers was rooted in their full-featured greatness. At the first hint of a bloated interface, everyone, business guy and geek a like, does what comes naturally. They put bugs in email. And email, we all know, is where bugs, features, and customer inquiries go to die. (Don't get me started on Yammer - we tried that too. Great for some things, not for this.)

And what about feature requests, support problems, or other non-technical tasks? Are they not as important to fix as the technical nuts and bolts? We believe that anything that gets in the way of a user accomplishing their goal is a problem. It might be a bug, some missing documentation, a bad marketing angle, or poorly thought out pricing. Why should bugs be singled out for special tracking?

So there we were, amazed that of all the bug trackers we could find, not one of them met our needs, which we'll summarize here:

Flexibility: Bugs and issues have some specific traits, but if you over-specify them, you wind up with confusion when the problem at hand doesn't' quite match up with what the software expects.
Simplicity: If everyone on your team doesn't use your issue tracker, it's worthless. It must be extremely friendly, because not using it is so darn easy. You don't work at IBM, where you can force a monstrous system on everyone. (Thank goodness.)
Cross-functional: Issues aren't just bugs. It's time that the marketing guys got in on the game and tracked their customer development progress with the same discipline that developers have used for years. Agile development requires that everyone be on the same boat, rowing in the same direction.
Optimized for Small Teams: We don't work at IBM or Microsoft. We never have and don't want to. TrackJumper probably does not meet their needs, and we're happy with that. TrackJumper is a tool for small teams working quickly. That focus is critical to keeping the tool streamlined. You can't be everything to everyone.

So stay tuned as we finish up the public release. Along the way, we'll post our thoughts on the world of software in general.

And for you early adopters out there, please email us at info@trackjumper.com. I'm pretty sure we can get you a free trial in exchange for some feedback.

Onward!