One of the most discussed feature requests for Lighthouse is the addition of custom fields. But given the goals of Lighthouse, it’s extremely unlikely that will ever happen. Why is that you say? Well – custom fields just don’t work, and here’s my argument for why that’s the case.
A little background
Before my work with ENTP, I worked at one of those big-bad-agencies for almost four years as a web developer. My job was not to write backend code. My job was not to make pretty designs. My job was to make it all work. Write the HTML, CSS, Javascript given designs from the design team and integrate it into Java/.NET/PHP backend systems. I was marrying the ideals from design and programming into the real world of a front-end user experience. Ideals don’t transform too well into the real world, so I ended up dealing with a lot of bugs.
A lot of bugs. During one of my projects, I estimate I was spending between 2-4 hours a day dealing completely with organizing bugs in our bug-tracking system, JIRA. JIRA had everything — access control, customizable workflows, priorities, rankings, modules, milestones and yes — custom fields. But at the end of the day, none of those features amounted to anything. It was just overhead that mandates more man-hours to organizing the bug tracker.
Organizing bugs is a myth
The basic idea behind custom fields is that you will be able to better organize your bugs and create complicated prioritized lists of work to be done. You’d be able to add a priority field, severity field, or a homeland security threat level color. The old prioritization system in JIRA I worked with prioritized bugs with two custom fields – priority & severity. We had three methods of making prioritization lists:
- Priority - This was the priority of the bug, supposedly set by the client
- Severity - This was the severity of the bug – whether it stopped all functionality, or was just a nitpick in the interface, for example
- Project Manager coming over, slamming their laptop on my desk and telling me to fix issue X.
Guess which method worked best? If you guessed #3 – you’re a winner. For all the prioritizing and severitizing (which costs a lot of time during bug input) the best method of bug sorting was human communication (WHAT?!).
Bugs really only have three levels of prioritization
Just because custom fields don’t work doesn’t mean you need to give up on prioritization completely. Simple prioritization can be a huge win for developers in allotting their time. But you have to realize that there are really three levels of priority for a software bug.
FIX IT NOW — these are showstopper bugs. The server is crashed, the code you just deployed is eating up $1500 in sales per minute. These are solved by phone calls, in-person sit-downs, raving emails and caffeine. No bug tracker prioritization will help you. Enter the issue into a bug tracker for reference, but the priority is right now.
Needs to get done very soon. These are bugs that break some non-vital functionality or produce a bad user experience and need to get fixed as soon as possible. We deal with these issues by tagging them ‘@high’ in Lighthouse. You should have absolutely no more than a dozen of these bugs at any given point. Any more than that will degrade to noise and developers will ignore.
Other bugs. Any other bugs should be prioritized via milestones and assignees.
Any other prioritization should be considered a recommendation and therefore as little time as possible should be spent creating the prioritized list.
The human brain is more boolean than you might think
Project managers seem to have a myth that the human brain works like a computer – where it can align priorities in a list and work on the issues in that order. Adding more developers to the project should work like parallel processors – they all respect the priority list and work on issues in parallel in order of importance.
The problem is that the human brain does not work that way. It decides what it wants to work on, makes it’s own judgement of it’s value, and makes it’s own decision. Realistically – this falls into one of two categories: needs to be done, can wait. This is why Getting Things Done (GTD) systems have a concept of things that need to be done today, and things that need to be done next.
If there is nothing that needs to be done, then people may reference a priority list as a recommendation – but they will ultimately decide for themselves. They may chose to clear out 50 easy browser bugs (low in priority) versus the one hard bug (high in priority) if nothing is urgent. Think about bugs like chores – do you take the trash out when it’s almost full, or the day before trash day?
Complicated prioritization lists are just false security
For all my arguments against custom fields, there will be plenty of people arguing the opposite. As a client-facing project manager, it’s very easy to think that you need to have complicated prioritization. You can produce lists of prioritized bugs for clients to look at and gush over. They are a wonderful source of false security — everyone not doing the work thinks everything is on track. “Look, we only have 5 high priority, showstopper tickets impacting the services layer for next month’s release left!” But the people on the ground working on the code know that’s not the case. Developers see the project as a whole.
Just because you can create a complicated hierarchical, phased priority list does not mean your developers will work on them in that fashion. I think most people underestimate the impact of personal communication and overestimate the value of technology. Bug trackers are a good thing, but only if they function with your team.
At Lighthouse we’re determined to make the best possible product – and we think the absence of a feature can be a feature in itself. Try working without custom fields for a little while and you’ll soon see how the glove fits.
Next up: How we work with Lighthouse - an eye into how ENTP uses it’s own bug tracker.
Loading tweets…
Our Products
Our Open Source Projects
- astrotrain – simply the best email processing solution out there.
- Seinfeld – automatic tracking of your open source contributions to github projects.
- warehouse – still using subversion? Get the best source browser out there.
- xtt – time tracking built for the add & twitter inclined.
- GitNub – OS X GUI for tracking git logs.
14 Comments
Well put. It seems like a simple GTD system vs. the bloated bug tracker would be a good indicator of (or maybe even product of) the focus of the company. Simple bug tracking lends itself to something like Results Only Work Environments, where hours are fairly unimportant. In companies like your former agency, where the drive is constantly towards billable hours, these inefficiencies can just be passed on to the client in the form of “project management.” No matter how inefficient everyone knows the system is, it ultimately makes the company money. It’s sad to think this probably will not change.
I’d be careful not to conflate “custom fields” with “desire to prioritize bugs according to a complex taxonomy.”
That said: there are only a few things custom fields can do that tags cannot, and I don’t care about any of them.
Andrew: Yeah, at first I didn’t want to either. But every single person I’ve seen talk about custom fields eventually brings their request back to prioritization lists. They usually start off saying that it doesn’t have anything to do with prioritization, but when pressed to further explain their viewpoint, they do a 180 and end up right back to prioritization of some form (be it through API calls, filtering, or extra information). Either that or end their comment with awesome ambiguity like “You wouldn’t understand, but this is 100% vital to my business and I can’t explain it.”
That being said, I would love to hear some real-world applications of custom fields that you absolutely could not live without (you in the general sense). I’ve yet to hear one argument in that fashion.
I like to add arbitrary metadata to tickets in the text of the ticket description itself, like:
Branch:
fix-stuffAnything that extracts that metadata and makes it more useful in any way would be neat. No specific ideas, just throwing something out there.
One ‘custom field’ would allow easy integration with other systems.
Without it, one uses tags as custom fields, and then you end up with an enormous tag cloud that is mostly noise.
For example, suppose you want to integrate your ticketing with something like invoices or purchase orders, or whatever. All you need to have is the invoice #, or purchase order #, or whatever #, inserted into that field. From then on, you are set to go without filling up your tag cloud with a bunch of numbers.
That’s the case that I present for having one custom field (one in tickets, one in messages), thus keeping the simplicity in place, alleviating the needs for particular users, and allowing an effective means for integrating lighthouseapp, via using the custom field as a hook, with other applications through the API. Can it get any better?
Peter Jaros and Raymond Brown: Machine tags would solve both of your problems rather well, I think.
git:branch=fix-stufforcrm:invoice=12345will be query-able by namespace, predicate, value and combinations of these. The UI can be like Flickr’s, hiding these bits until asked.Kyle: Consider the laptop slammed on the desk. :)
As an ex-proponent of Really Taxonomized Things, I want to add:
Custom fields were just a placeholder for full-text search.
Think about it. Even in a complex organization – and I have been in 40-person meetings where every single person there really WAS needed, given our structure – you don’t need the full N x M mesh of bug triaging.
You need to know “which bugs are preventing X”, where X may be the new joint venture, or the client launch, or the trade show. But joint ventures, desktop clients, and publicity events are orthogonal.
So in the old days, with a strongly-typed database and strict validations, the only way to answer questions like “which bugs are preventing X” was to enter ALL the data ALL of the time. Every time you discovered an X-stopper that couldn’t be queried in the bug database, you tried to add it – and more often than not, this meant adding yet another field.
But that was then. That was when the idea of full-text search was something that was the province of PhDs in linguistics, not a small feature that came free with Postgres.
Nowadays, you can just add “needed for COMDEX 2008” into the comments field, and you’ll find it later when you search. Because even though we had a “Required for which trade show” field on every bug, we didn’t really care about every trade show that might theoretically be affected by the text-area bug; you only care about This Big Tradeshow and what’s on the critical path. Most importantly: You don’t ever need an authoritative list of bugs that AREN’T trade-show-stoppers.
It’s the same reason we don’t have to spend hours organizing our e-mail into folders; the same reason we no longer care about Yahoo’s site classifications. We don’t have to anymore.
It was a false dimension in the database. A placeholder. We’ve moved past that now.
I think Richard hit the nail on the head pretty well there—we use namespaced tags (machine tags, however you put it) whenever we need advanced filtering.
Jay: Excellent point, don’t think I could have said it better.
If tags are so effective then the logical conclusion is to track EVERYTHING though them that is currently in the drop down fields! :-) This is not much more silly or extreme than stubbornly suggesting custom fields have no legitimate utility to any of the user base. Can you just let the users decide when and where fixed-list fields are appropriate (if at all)?
You know what would be a cool feature!
...Being able to make a list of bugs and divide it into two lists: a list that developers see, and a list that just you see. And then you can set some sort of timing options of when to release the bugs to the developers so they’re never overloaded and it all appears to be noise. For instance, you could set the maximum number of each of the 3 bug priority types allowed on a developer by developer basis. And you can set another option to only reload a developer exactly when he he completes all his current tasks, or set it to “keep it coming.” There’s a probably a few other settings that can be done, but you get the gist…The idea is that it would allow you to do major QA sessions and not immediately make a developer’s like unmanageable…Another way, apps like Rally do this is by making developers have to accept tasks, etc. Since bugs can be very related, sometimes it’s good for the developer to be able to see the whole picture and pick and choose himself, but if you have a relatively good project manager who’s pretty much in the trenches, he’ll know what to give to the developers and what not to give.
There are some really simple areas where custom fields can be appropriate, and tags don’t work as well.
The simplest one I can think of is numeric ranges.
Lets say I want to keep track of how much time is spent on tickets. I could use this value to calculate billing hours. I could also use this just to keep track of where we’re spending our time. I may want to look back and see how the business could be improved. For example: Man, we’ve spent a lot of hours of development on this feature every couple months, and no one uses it.
I could start putting numeric values in tags, but that would quickly become ridiculous.
Having worked at companies that have abused very large powerful CRM systems like remedy, I know how it is easy to abuse these things.
On the other hand though, it seems like a relatively easy feature that your customers want.
This “defining priorities is a myth” talk kind of smacks of the possibility that you guys may be drinking your own kool-aid just a little here—instead of focusing on creating a simple product that meets your clients’ needs.
I get wanting to avoid customer-driven feature-bloat. And “custom fields” sounds like feature bloat.
But guys: the ability to assign Priority levels to bug- and feature-request tickets is fundamental to a sane, agile development process, and to good developer-client relations.
If lighthouse is to be viable for our company, we need (and our clients demand) the ability to assign priorities when tickets are posted. Otherwise we’re forced to work outside the system to communicate these things – which means the system is broken, branching and becoming even more complex.
I can’t speak for all your other customers on lighthouse, but we are a customer, and we are suffering without the ability to prioritize within the ticketing system.
I’m alarmed to read, here, that in your minds, you’re grouping something so simple and sane in with “custom fields”
Prioritization is structural to the process for many, many development shops. If not all.
The best article I’ve read on priorities is priority zero
Also: did you know you can prioritize in Lighthouse? It’s on the Milestone screen. You drag-and-drop the tickets in priority order.
We had only one custom field at my last job: “Issue Type”. It was a field that could have been accomplished with tags, but the field was very logical to employees. It also forced a value to be set. It only had 3 options: Software, Hardware(Electrical), and Mechanical. It made the bug system easier for employees to use.
Make your voice heard
Sorry, but comments are closed for this item.