To add custom/user-defined fields feature or not?

Question

This is more of a product philosophy/software architecture question.

If you are writing a business application, groupware, bug tracker, etc. you'd come across a client demanding "I want field XYZ in this entity." You know the field is too specific for the organization's needs and/or the terminology does not fit your product.

Do we give in and support custom/user-defined fields, or stick to small number of fields (my way or high way), or keep adding everything that every client demands? Why?

If you do support custom fields, how would you define UI, business rules, database scheme, reporting, etc.?

Answer 1

I've used tags as an escape valve in such a situation.

Answer 2

This can be handled by a configurable UI, a good middle-tier and an advanced o/r mapper. We do it like that. But that can be a lot of work. So I guess the answer is: It depends...

Answer 3

My paradoxical answer would be, consider having ONLY custom fields. Let me explain.

I totally, totally relate to this question. I'm the author of BugTracker.NET. At first, my philosophy was "my way or highway", but I did give get convinced to support custom fields. At first, the custom fields didn't behave as well as the built-in fields, but over the years I've improved the behavior of the custom fields to the point where their behavior is nearly the same as the built-in.

So, I'm kinda, sorta thinking:

The codebase would have been cleaner if I had implemented the built-in fields as custom fields. That is, the built-in fields would have been just a set of pre-configured fields out of the box, that used the same mechanism as client-added custom fields. Right now, throughout my app, I have blocks of logic for the built-in code and completely different blocks of logic for the custom fields. There could have been just one block, for the custom.

I don't think you would want to add everything that any client ask for. Simplicity is a virtue, and every field you add, while making one customer happy, risks being perceived as clutter and complexity by others who don't need the field. People who like BugTracker.NET often mention its ease and simplicity. People who don't like it mention that it can't do something complicated that they want to do (usually related to permissions, another part of an application that can be a big mess). Without a good infrastructure for custom fields, you have to balance the two audiences, but with a good infrastructure for custom fields, you can keep it simple out of the box and let the folks who like complexity make themselves happy.

Answer 4

This question lives in that precarious balance between a focused-featureset and creep management :)

It's a gray area that may require the following:

• User training (oh! feature FOO can take care of that!)
• The parking lot (is this a feature you actually need? Park it for now, and if it keeps coming up, then work it in)
• Stakeholder redefinition (a new or unexpected group is benefiting from your product...if only it had BAR)

In short, I don't think adding custom fields, or giving folks tagging ability is necessary. If you've got a well-defined audience, a solid feature-set, and adequate documentation, then where is the need for this feature coming from?