Fog Creek Software
Discussion Board

On FogBUGZ And Custom Fields

Joel - I just read your angst over whether or not to support custom fields in FogBUGZ.  I can relate - I worked for a small company that produced a product in which customers frequently wanted to store "custom" pieces of information.  Like you, we often found that the data our customers wanted to store could be stored in existing fields (proof positive that Customer don't read the manual).

The compromise position we took, and one that you might want to consider, was to offer the customer a fixed number of custom fields.  In our case, that number was ten.  Those 10 fields could be defined by the customer and used to store any info they wanted.

This seemed to benefit the customer because it forced them to actually THINK about which bits of data truly needed to be in a custom field and which did not.  Initially some customers pouted because they could not have an unlimited number of custom fields.  But in the final analysis of the pouters, it was a rare customer that actually used all 10 fields.

So, take that for what it's worth.  It's something to think about...

Thursday, September 12, 2002

The question of custom fields (or custom information) in a bug database is an interesting one.  With our product - we get bug reports from the field that contain a minimal amount of information already.  To ask these users to enter more information is not likely to result in more accurate reports - rather I suspect we would just get fewer reports.

One of the best approaches I've seen require the user to enter less information - and then have a special application fill in the rest (Netscapes talk-back and Gnome's Bug-buddy come to mind).  Stuff like log files, system component versions, configuration, and even stack traces (watson logs, core dumps, etc.).  Less effort for the bug reporter, more bug reports ... and more information for the people who need to reproduce the problems.

The key, as I see it, is for a better user experience when reporting bugs.  This means simple, effortless, fun even (it such a thing were possible).  Really, products get better when more bugs are reported - and getting the gritty details is not something anyone should drag their users through.  Make it fun!

Bruce Alderson
Thursday, September 12, 2002

In a prior job the help-desk software package was selected because the manager could add (and remove) fields and rework the reports. He proceeded to basically re-write everything that could be re-written - it would have been cheaper to give him a copy of VB and let him write it from scratch...

I like the idea of providing 10 (+/- 3) fields that the user could define. In addition, make sure that they can put the proper label on them - there's nothing worse then trying to remember what goes in the 'user1' field. being able to define simple validation rules would be nice too (i.e. numeric v/s text).

Thursday, September 12, 2002

This is an interesting topic.

Should we "do the right thing?" or "do what the customers ask for?" 

First, if you think you're right, be very, very sure you're right. In this case, I think Joel is generally "right."

To do what the customers ask for...classic marketing issue. Are they sure they really know what they're asking for? Joel suggests that in many cases, they don't. However, you certainly don't want to be condescending to them. Joel's approach in the article is well-worded, to empower the customer, not belittle them. Sometimes, they don't know what they want, and that's not officially bad. Maybe you can take the opportunity to educate them gently.

The risk Joel faces is that if FogBugz supplies the feature, and the sites that install it misuse this feature, users will think "fogBugz is terrible!" This hurts the reputation of the product. From a business standpoint, will that cost more sales than the sales lost due to the absence of the feature?

My opinion (which is worth every penny you paid for it) is to keep the usability and delay adding the field as long as possible.  Those that insist on the feature are probably more likely to misuse it.

I come to this opinion because it seems that underneath it all, Joel would like the software to encourage and support good software practice in organizations, whether they are directly seeking this or not. Therefore, make the bug reporting system easy to use so people really use it, so you actually track your bugs, and so you produce better software.

Lauren B.
Thursday, September 12, 2002

One of the persuits that is generally futile is to attempt to convince customers that you are lacking a "popular" feature. 

There is one set of customers that buy a bug tracking application because they've been told they need one, and that turns into a search for the best, which usually means that the one with the most features wins.  In general terms, these are the clueless.

There is another set, that will buy a bug tracking application and misuse it as a work management tool... which enables them to continue their "hands off" approach to managing developers.  This group puts all kind of requests and projects into it, and expect the product to manage their people.  These are the double clueless.

Then you will finally get to the set that wants a bug tracking application, and will use it effectively.  They won't want to spend a great deal of time learning it, and they won't use existing features to make it into something it is not.  Simplicity will sell them.

So the question becomes... which set of customers do you want to support?

There is a point in the life cycle of any product when development on that product becomes "customer driven"... features are added because "some customer wants it" and that is the extent of the reasoning applied and becomes the decision process all in one.  The product will decline in these twilight years, as the vision and innovation that made it a worthwhile product in the first place gradually disappears.

Add a custom field feature if you believe it will enhance the usefulness and functionality of the product. 

Perhaps a site visit to a customer or two that is demanding or requiring this (or any other for that matter) feature would be worth your while. 

Then decide based on your willingness to have your product associated with this company's particular way of doing business.

Joe AA
Thursday, September 12, 2002

(Aside: The problem I have with the various tools that automatically enter stuff into the bug report, is that they get this information from the computer that I am using to type the report. Makes sense, from a certain standpoint, BUT--- I rarely, if ever, enter a bug straight from the system where I encountered it. Chances are, the test system isn't even networked. Bugs get entered from my working machine, and my working machine is never purposely used for testing.)

As far as the question of custom fields--I agree with your philosophy, Joel. Bug reports should be as simple as possible. Extra information can, and should, be entered in the description section. But--the customer IS always right. Even when he's a complete moron. And once he pays you, what do you care whether he has four hundred fields? (Well, I suppose there's the issue of the users blaming FogCreek for the unusability of their system, when it's actually the PHB's fault. But if you make the custom fields always *appear* custom, even that can be minimized.)

If you're losing customers because they think they need custom fields, there's no debate: include them in the next release. To appease your conscience, you can severely limit their number--say, no more than 5.

Thursday, September 12, 2002

well said Joe AA

Prakash S
Thursday, September 12, 2002

Another idea is to allow custom fields, but don't enable the user to make them compulsory. This way, users who know better than the PHB can just enter their bug quickly and get on with their job. It might even show the PHB how unneccessary and annoying all those extra fields are!

Darren Collins
Thursday, September 12, 2002

It is a very interesting debate. I work at a company where our flagship product, a web-based intranet, didn't start as a product at all. It started as a an internal tool for ourselves (I think this might be true of FogBUGZ as well?).

As a result, we got to make the call of what got included and what didn't. The developers were the users. The result was great - we ended up with an efficient and smart system with no fat or speculative features.

Now the system is being sold as a product, we've needed to look at what other companies and people might need in this kind of system, and like Joel, we've had to balance needs that we perceive in the market, and perceived wants of the potential customers.

I had an interesting debate with a friend last year about developers as dictators. I was ranting about how I hate skins in software. He accused me of being an arrogant designer that thinks people don't know what's best for them. I hope I'm not arrogant - but I do think that users often don't know what's best for them. For example, a user might pick the coolest looking skin for an application, only to be frustrated later by the tiny and obscure buttons and controls. Sometimes, the user won’t even make the connection between their frustration and the skin they chose.

Customization is often used as a crutch in design. Can’t figure out which option is better? Make it an option.

So what are we to do, rule the users with what we think is our benevolent hand, or give them what they think they want? Since we’re talking about software here, and not politics (though Laurence Lessig would argue that software IS politics), we can exercise control. This leads to marketing issues - like Joel’s potential customers who think they need custom fields, and might give their cash to someone who will give them what they think they want.

I have a possibly naïve hope that in the long term, a useable system will win out because it works well as you use it (rather than appearing like it will work well before you use it). However, I fear that the market has a lot more to do with voodoo than quality.

Steven Garrity
Thursday, September 12, 2002

Anecdotal evidence:

Just this morning in our weekly meeting 2 issues were raised with the custom fields we added to our bug tracker. One was "What supposed to be entered in this field?" and the other was "I didn't know that field ever got added". Obviously we really don't need them.

Probably the suggestions to limit custom fields make sense.

Thursday, September 12, 2002

This harks back to the "Templates - bad idea" article.

Big companies often use RFP templates to weed out competing products.  The contracting folks pull out the template from the file of their last RFP.  It probably has a "custom field" check box.  There is probably a checkbox for every feature ever needed for any product.  Who in the purchasing process wouldn't check it?  There might be many folks on the product selection team who don't track bugs or at least have never though deeply about bug tracking.

They meet to review the checklists so they can narrow the vendors from 10 to the 3.  The team only invites 3 venders to a site visit to make in-person pitches.

Fog Creek needs to make that cut just to eplain why they should be wary of custom fields.

Thursday, September 12, 2002

Custom fields are obviously a good idea, if many people ask for them, even if there clueless one way or the other, there's probably a valid reason for it.

The biggest drawback of custom fields is excessive use and misuse for all kinds of irrelevant data. The solution I choose was to link the custom field to specific projects or categories. After all, a bug in a geographical system might have use for a field "City" but it would be useless for a bug in a number crunching algorythm.

In short, let the abuser suffer the abuse.

Geert-Jan Thomas
Friday, September 13, 2002

Re: the big RFP report.  When I was doing enterprise software sales for a med-small software company, our policy was "never say no" on a question as to whether we had a feature.  (at least during pre-sales).

Every feature on the list we said yes-- it was either in the core product, or we would create a customized module that would support it.  In the rare case we felt we couldn't justify checking yes we would say "n/a" meaning that feature was really just not relevant to the customer problem!

Incidentally, the reasoning behind this was that such lists are really a "deselector" designed to eliminate vendors from the list before considering a proposal.  We always felt the best case would be made through in-person meetings and proposals.  (worked great for several years until we sold one large project completely beyond the capability of our tool.  When the project failed to deliver, the client-- I think in hindsight quite reasonably-- refused to pay)

The voice of rationality
Friday, September 13, 2002

This question can be resolved fairly quickly by asking one simple question:

What is the ROI?

The investment in this case is roughly a week of developer time, including testing.  As such, this is a minimal risk on the part of the investor (Joel).

It has been identified that sales have been lost in the past to the absence of this feature.  It stands to reason, that by adding it, increased sales will result in the future.

Now, what about losses resulting from the implementation of this feature?  A loss of sales doesn't seem to be realistic.  However, what about increased tech support?  This is a proabable concern, however this a variable known only to Joel.  Despite this, I can only assume a minor increase in concerned customers.

In summary, the ROI on said product feature indicates to be particularly high.  Thus, it would seem prudent to implement custom fields.

Friday, September 13, 2002

'our policy was "never say no"'

And people wonder why software salespeople are mistrusted both by the prospective customers and the people having to make good on their promises.

Simon Lucy
Friday, September 13, 2002

On the subject of listening to your users, which is, I think, a meta-issue round the custom fields discussion.  I like the advice of Nathaniel Borenstein in "Programming as if people mattered". The chapers is "Listen to your users but ignore what they say" and this quote gives you an idea of the perspective. 

'"t may help to think of the user community as being like a preschool full of screaming three-year-olds. One doesn't have to rush to respond every time one of them cries a little bit, as crying is entirely natural for young children. But if some or all of the children begin to wail frequently, something is probably wrong, and an investigation is warranted. If what they're all crying is "I want a cookie," that doesn't necessarily mean you should give them all cookies, but you might consider amking them a healthy lunch to meet the underlying real need."

Of course Joel seems to be talking about what people who aren't already customers are asking for, and I've also heard what I consider the cynical view "ignore your current customers, they've already paid their money, you need to find out why the rest of the market haven't bought yet".

I'd vote for adding a small, fixed number of custom fields so that you can make it through the feature checklist bakeoff. Hopefully once you get through to the part of the bidding evaluation process where the actual software and the tasks it supports are evaluated it will be seen that the fields aren't needed anyway.

Alex MOffat
Friday, September 13, 2002

"In summary, the ROI on said product feature indicates to be particularly high."

A great example of why ROI is not a measurement to be used in and of itself.

I am more likely to buy from someone whose products I am in the habit of using.  Since Dreamweaver is incredibly useful for me, I look first to Macromedia for related products.  There are other development products I tried out, kind of liked, even bought a few...but I could not tell you who made them or even what they are called.  Needless to say, they have zero presence in my mind when it comes time to shop around.  But they made a good return I'm sure on my first purchase.

In the short term, you will sell a few extra copies...ROI is high, and the analysts are pleased.  In the long term, you wonder why you can't get any repeat business or why customers have only a hazy-at-best recollection of your products that are collecting dust on the shelf. 

If you plan on selling the kind of products that people only buy once, yes...focus on getting that sale and the return on initial investment.  But if you are planning on repeat business, an upgrade cycle, support contracts, or getting _anything_ from the value of a good customer relationship, selling a product that the customer won't use is a great way to shoot yourself in the foot.

Kevin Williams
Friday, September 13, 2002

Do you believe that your system encapsulates purposeful design to enable the effective tracking of bugs?

Then why mess it up for all your existing customers in order to satisfy a few potential customers?

Instead, why not go the "meta" route.

Have a user configurable screen facility with a maintenance function.

They define their logical screens, fields, datatypes and labels (ad infinitum) and the order in which they appear.

Your underlying physical screen displays them in order, but all the same size, ad hoc scrolling etc.  Don't skimp the data validation, drop lists etc., but don't make it look pretty, maintain distance from the designed product.

The data storage: simplistic, inelegant (untyped), but effective.  Searchability, likewise.

Now your sales people can say that you can do it.

The buyer types with wierd preferences can wet dream themselves to ecstasy over the possibilities (which most will never implement once they have the system).  (I would argue that buyers are the root cause of many of the problems we attribute to salespeople.)

The users, when they get the system, can mostly ignore these facilities, aren't constrained to use them, or even to see them, and can drive the system as it was meant to be driven.

It's the "ground effects and spoiler" kit for the buyer who values form over substance.  But it works for the few who genuinely have tuned the system up to the point where it needs them; and it doesn't offend those who don't want it.

Attending the wake
Friday, September 13, 2002

On "never say no.'  The "big" RFP process is tough on buyers and sellers.  I worked on about 100 of them.  Preparing and editing several hundred pages of RFP, trying to engage the folks in-the-know to prepare requirements (who are busy because they are in-the-know).  Then reading the 10 or more hundred page vendor responses.  From Animal House, "It could take years and costs thousands of lives."  And that's before grinding through the process with the 3 finalists, signing a contact, and implementing the system.

The best vendors understand the RFP process better than the buyers.  I won't say they lie in their reponses; I say that they are selling.  They do their best to become finalists where most of the details get vetted and resolved.

In my experience it was an unpleasant experience for all but it usually worked.  The implementation is the hardest part anyway.

Friday, September 13, 2002

Don't make the mistake of assuming your own knowledge and experience can be used to define what most customer's situations may be.  While we (in IT) try to think of every conceivable angle when developing software, there are always situations out there that do not fit the mold of what we can design.  Let them have the custom fields.  If they abuse them, you can go to sleep at night knowing you were right.  If they find new, creative and possibly customer specific uses for them, you win again because your product is much more usable to the customer.  Moreover, let the customer decide the type of field is should be (list of values, radio button options, text, etc.) and where it should be placed.  Give them the ability to filter and sort on the fields

Oh yeah, keep asking for feedback on what fields a customer would like and how they are using the custom fields.  We all like to snicker at the mistakes people make with a product, but I would be willing to bet there are many more legitimate uses of custom fields.

Jim L.
Friday, September 13, 2002

5 custom fields max and the user should be able to label them. CityDesk should do this.

Friday, September 13, 2002

I would guess personally that ten fields should be enough. However from my experience here the following points are worth mentioning:
a) fields should be indexed
b) fields optionally compulsory or not
c) fields optionally a drop down combo box
d) Default value allowed, even if it's (none)

OS version is a classic example of something that shouldn't be free form text. There aren't too many windows versions: 95,95OSR,98,98SE,ME,NT4,Win2K, XP plus an other/unknown option for completeness.
At least then if you're trying to track down a bug you would stand a chance of being able to filter / sort the reports back out. Free text just doesn't cut for this.

Actually I reckon in practice a simple 9x / NT box would be good enough but thats because many bugs are either UniCode or security related and that's where 9x/NT differ the most.

I've found the OS version and Network type to be most useful when trying to sort out "Cannot reproduce" bugs, particularly now when most developers have made the jump to Win2K/XP

My personal experience is from an accounting package point of view where people use these fields a lot to analyse data. I've not used FogBugz but I would suspect many folks would like the ability to add custom fields. Limiting the number shouldn't however be a big problem.

Peter Ibbotson
Monday, September 16, 2002

Maybe I am missing something here. Why does Joel care whether or not the customer uses custom fields? If s/he wants to track the version number of every DLL, who cares? Beyond the initial development, it's no skin off of Fog Creek's nose.

While I agree that there is a high potential for abuse, I think that if the customer is asking for rope to hang himself -  give it to him and walk him to the tree.

John S. Dawson
Monday, September 16, 2002

>if the customer is asking for rope to hang himself -
>give it to him and walk him to the tree.

I beg to differ. I worked at a place before where we customized the application for every customer that wanted it customized, and it had the result of a worse product.

If you are working in a shop that creates an application, doesnt matter which, working with many customers, you are going to gain expertise within the domain of the application. So when John Doe comes asking for features that you know will not work, you should not give it to him.

Maybe you will loose one sale, but that is usually cheaper than keeping him as a customer, doing customizations to no end, becuase the user has  a poor grasp on system development.

Just my 2 cents

Tuesday, September 17, 2002

I respectfully disagree. I work as a software engineer for a Fortune 500 semiconductor manufacturer. This industry probably leads the world in the volume of manufacturing data collected simply due to the tremendous complexity of fabricating ICs.

We are constantly being asked to collect more and more data in various ways. Far be it from me to tell an engineer that he simply doesn't need the data he is asking for. My job is to give them the data they need in a form that allows them to make decisions.

Again I ask, why do we, as developers, care what data the user wants to collect. Are we saying that we know better what s/he needs? I think this type of ivory tower mentality sometimes gets us into trouble.

If I live in some artic region and I want a car with air conditioning, who is the manufacturer to tell me that I don't need it and can't have it?

John S. Dawson
Wednesday, September 18, 2002

>If I live in some artic region and I want a car with air
>conditioning, who is the manufacturer to tell me that I
>don't need it and can't have it?

Ok. I see your point. I can borrow Graucho Marx words,
to defend my earlier post. "Those are my principles. If you don't like them I have others".

On a serious note, in my experience, if you are deploying a new application, you also need to change the ways the business people do things. If you allow customizations, most people will justify changes with "Well, you see we have this here field in our current application, and we absolutely positively need that". Then if you tell them,
"Ok, we collect that data over here on this other form", they will not think of that as being acceptable, since they are trying to customize the application to their current way of working.

In my oppinion, you need to change the way you work, as well, when you decide to replace an application, or you will never be done with your customizations. Thus, do not allow them.

However, if you have had a deployment at a customer, and they decide they need to have another field or whatever to collect something they just thought of, thats no problem.

Another 2 cents,

Thursday, September 19, 2002

In some trades they have a "f*off" price for jobs they don't want (ie at least twice the reasonable price). Why not have two versions: one at a reasonable price, and the customisable fields one at an unreasonable one?

Thursday, September 19, 2002

I haven't been in need for a new bug tracking system any time in my career, but if I was, FogBUGZ would be first on my list.

Why? Most importantly, because I know it is made by Joel Spolsky, and I have come to really respect Joel Spolsky's opinions when it comes to user interfaces. In addition, FogBUGZ is simple, and I really like simple.

Now, if Joel Spolsky does not follow his own advice in the programs his company sells, how would that affect my opinions? I would respect Joel Spolsky's opinions less, because he didn't follow them himself. And with that weight of the scale, I would not give FogBUGZ a second look. If I expect all my options to be complex and require lots of work, I would rather go for one that is free and complex and requires lots of work.

I bet Joel sells a lot of copies on his status among software developers alone. How wise is it to jeopardize this status for a few more sales in the short term?

(As a side note: I had to stop using Emacs because it is too configurable. I spend more time configuring in than using it)

Thursday, September 19, 2002

> Again I ask, why do we, as developers, care what data the user wants to collect. Are we saying that we know better what s/he needs? I think this type of ivory tower mentality sometimes gets us into trouble.

Reality check! Of course we can't know each user's <i>exact</i> needs. But we do have much more experience than most individuals and part of the value of the product is that experience manifest in the product's design.

We know that asking each user to list the version number of every DLL in the system means that fewer bug reports will be submitted. Does the buyer know this? Probably not: they're unlikely to think beyond the "Wouldn't it be cool if...' or "Can I tick this box on the feature requirements form?" Our experience allows us to make a real contribution.

A recent poster alluded to this with his/her "we'll respect Joel less if he doesn't follow his own advice comment."

This issue (perceived value vs. actual value) needs to be addressed at a much more fundamental level, but it would be defeatist and ultimately destructive to conceed with "the customer is always right, even if they're wrong," i.e. "I'm not sure which is best, let's make it an option."

Tom Payne
Thursday, September 19, 2002

You can have your cake and eat it too. Add the feature; your livelihood may depend on it. But design your software AND documentation well: When the customer opts to add his/her own fields, make them easy to spot visually in the UI. But de-emphasize the feature in your doc/help files. That is, make it easy to find out how to use the feature, but clearly state, much as you did in your article, why it may be better not to use the feature.

Do yourselves and your customers a favor: don’t offer 2 versions of the same product (i.e. “platinum” and “el cheapo”). I hate sorting through the differences btwn a vendor’s product levels. Even if you determine you don’t really need the platinum features, you always feel like you’re missing out on something anyway. And sure enough, the vendor will come out with some great add-on benefit, but only for “platinum” users. Don’t go there. And of course, as a developer, it can get tedious supporting both platinum and el cheapo.

Tuesday, September 24, 2002

1)  The product vision is of a simple bug tracking system whose design lowers the resistance of reluctant users to adopt the product.  As it says on the home page, “FogBUGZ is a web-based system that has been carefully designed to eliminate the obstacles that keep people from using bug tracking software. It is the first viral bug tracking system: it only takes one programmer, tester, or manager to start using FogBUGZ, and within a short time, it will spread to the whole organization.”  This is guerilla software.  Someone wrote above that it’s important for products to be true to their vision.  Letting users customize the software is not consistent with the vision of this product.  Let people who want feature-rich, highly customizable software buy something else.  2)  This product is targeted at a segment of the market, not at all software development organizations.  In my opinion, the market segment is small teams that use informal development processes.  Why?  Three reasons come to mind: its low price ($2000 for a site license?), its lack of compatibility with multiple version control systems, and its support of only one O/S.  Does the product's market segment need the ability to customize fields?  Probably not.  3) Joel is taking the position that customers say they want custom fields but that they actually need to store data which already has a home in FogBUGZ.  The customer problem, therefore, is not a lack of custom fields, it’s a lack of understanding of how to use the product.  The solution is to provide better information about how to use the product.  4) The need for custom fields is coming from sales, not from tech support.  It’s not that existing customers are trying to push the application to support new cool stuff; it’s that people shopping for a bug tracking tool think they need custom features.  So the strategy ought to address the sales and marketing process, not the feature content.  5) Don’t be too concerned about losing out on a sale here or there.  You will get more sales by strengthening your marketing then you will by adding custom fields.  6) The comments above about RFPs are interesting, but from a market segment point of view, I do not think they are germane.  Sales in the small informal team market segment isn’t driven by RFPs.  Such orgs don’t have the staff or the bureaucracy to use a formal product proposal process.  Even if the team is part of a huge global high-tech company, there will be small departments and teams that will buy stuff outside the formal purchasing process. 

Tuesday, September 24, 2002

Joel, you want to reach two, in this case competing, objectives at a time: (potential) customer happiness, probably translating into more sales, and software quality as judged by yourself and many other experienced people.

I think a limited introduction of custom fields, regardless of their number, leaves you with the same problem you're facing now: Clueless managers will compare their feature check-lists and dump FogBUGZ because it allows only x custom fields compared to the competitor's infinite number of those.

So, I really propose the solution you mentioned at the end of your article -- mostly as a joke as it seems: If you think those lost sales are important (huge) enough for your company, implement "real" custom fields, i.e. as many as people like, with their own captions and maybe some simple validation properties. But hide them behind an additional link in every form (entry, search, display) where they will get in everybody's way. So you can offer the feature while still enforcing simplicity for everyone but the few guys who really do the additional clicks to find and use it.

Philipp Rotmann, Germany
Monday, September 30, 2002

*  Recent Topics

*  Fog Creek Home