I posted last week about how feature bloat can ruin software.  Adding lots of small features to a project doesn't just add harmful bloat, it slows down real improvements.

Several times per day something comes up where five minutes of coding could significantly improve our software.  When this happens, I add that idea to "the list".  Everyone at the company knows that when something goes on the list, there's no telling when (or if) it will ever be completed.

I'm going to use this post to defend that way of doing things.  It's really easy to say, "but it would only take five minutes.  Why don't you just do it now?"  The simple answer is that while one individual improvement only takes five minutes, I have about 200 small things on my list.  If a developer stops to make every little tweak imaginable, the software will suffer.

No amount of tweaks will ever add up to have the impact of a well planned and carefully implemented week-long project.  This is one of those situations where the whole is greater than the sum of its parts.  One block of five minutes is certainly better spent on a small fix than a week-long project, but a week of small fixes can't compare to a week focused on one important problem.

Additionally, it may only take five minutes to complete a small project, but it could take 30 minutes or more to get back in the flow of whatever you were working on before the interruption.  It's hard to say "no" to little things, even if only temporarily, but it's irresponsible to let yourself become distracted from the real work.

And that's what the title of this post is talking about.  Just because something only takes five minutes, you should still treat it like a project.  You should still put it on a list and prioritize it just like you would a month-long project.

Each day I get into work and decided what I should spend my time on.  This is based on which projects I think have the best chance of improving our customers' experiences and help our company grow as a result.  When that idea for a small tweak that would make everything better comes in, I have to remember that I'm working on my current project for a reason and that's because it's the most important thing right now.  The tweak can wait.

There's a pretty easy compromise for programmers.  We generally deploy new code every Friday evening.  I don't want to get into the details of our version control system, but deployment is a lot easier if I don't start any other major projects until the old ones have already been released.  That means that if I finish a couple hours early on Friday, I can spend that time checking items off "the list".  This is a great way to make sure that the little things get fixed but that they don't take over my week.

Feature bloat is a really serious problem for anyone responsible for creating a product.  In software, "Feature Bloat" happens when developers keep adding new functionality to a program.  Eventually the program becomes so complex and messy that it's not good at anything (think Microsoft Project).  A fellow programmer joked with me that the first law of product development is that every piece of software eventually turns into an email client.

The problem is that it's really hard to say "no" to good feature requests.  Maybe a large client is starting a new project and they say they'll use your software if you add one basic feature.  Then another client suggests another and so on.  If you say yes to all these simple requests, it ends up ruining the entire user experience (even for the people that originally requested the features).

The current Zane Benefits CRM is actually the third CRM we've developed.  The other two came before my time, but they showed me two very dangerous pitfalls that I made sure to avoid with the most recent version.

Problem #1 - Too Specific

One of our CRMs was designed specifically for insurance agents to use as an individual insurance sales tool.  Of course we ended up getting users that didn't fit that model (another example of assumptions gone wrong) and our tool was just completely out of its league.

Problem #2 - Supporting Too many cases

The other CRM was only for our internal use so we ended up tweaking it all the time.  When we started our first mailing marketing campaign, we added a field to each contact to record that info.  We sold group insurance for a while and we had a way to track that.

It seems like this is the opposite of #1, but it's actually a close relative.  It's easy to think that the way to avoid being specific is to support as many different use cases as you can think of.  This generally fails because no matter how much thought you put into a program, you'll never be able to guess how people will use it.  To compound on that, supporting a bunch of different things will clutter the actually useful functionality so much that no one can figure out how they should be using the software.

So how can we avoid feature bloat without losing all the functionality the users are asking for?  It's actually pretty simple in a lot of cases.  Just make the foundation of a program as flexible as possible and that will allow you to come up with a native solution to just about every problem.  Rather than building a way to record marketing campaign information and a way to track group insurance sales, just make a system that lets users track whatever they want and then set up smart defaults for them to keep things simple.

Our new system only has a few ways to record information about a contact.  There are "pipelines" which track any type of ongoing communication (generally specific sales), "notes" which are just text fields for whatever the user wants to remember, and "lists" which are basically like labels in Gmail.

Now when a client calls up and asks us to add a field to the contacts with information about which mass mailings they received, we suggest that using a combination of lists and pipelines can solve that.  If a user wants a tool to migrate data, lists alone can solve the problem without us building a dedicated feature.

By making our very basic low-level infrastructure as general as possible, we left the door open for our users to turn the software into whatever they want.  The days of a company telling users what to do with a product are over.  Our users are teaching us how to use the very thing that we built.

It's still hard to resist feature bloat, but it's a lot easier when you do things right from the beginning.