What is 'feature creep' and the problems it brings

If there is one thing that programmer's love to do, it's to code new and exciting things. They love designing them, implementing them, testing them (hopefully) and launching them to a wide-eyed market of folks who have no idea what you are building or why they need it. But it's a great time to test out one's creativity and to get away from the usual maintenance routines that most developers spend their time doing. And there's nothing wrong with it to a certain extent.

Writing code for an employer is much different than writing it for yourself, however. There are many more variables that need to be taken into account, such as deadlines and co-workers. So while there is nothing wrong technically with writing alot of code, it could begin to cause issues for you down the road in a more professional setting.

It may sound like a cutesy problem to have, but it is probably responsible for companies shutting down and for millions upon millions of dollars lost in revenue and high programmer turnover. And if that sounds like an extreme hyperbole, then perhaps it is. But featuritis is very much a real thing and it is indeed responsible for those things to some level and in some combination. So today, let's go over some of the effects that writing too much code can have on both yourself and on your co-workers and on your company.

You undoubtedly introduce new bugs

Bug-free code does not exist. Mainly because most bugs are logical in nature. That is, they are dependant on outside factors in order to be considered bugs. Consider the following example. You have a payment system on your website. Every time there is a transaction, there is a 5% fee added on top for maintenance. Easy enough. You charge 5% each time someone hits purchase based on their total. One day you have a fantastic sale for 5% off across your entire store. So you must implement some type of coupon mechanism into your website.

Your company would of course rather have you charge the maintenance fee before the coupon is in place. But that's not how the logic works. The maintenance fee is charged at the very end. Which is perfectly functional and logical. However, because of outside factors, such as what someone else expects to happen after the fact, the logic would be considered wrong and hence you would have a bug .

The point here is that the new coupon feature has introduced a new logical bug. One that didn't exist before. Most bugs on most websites are due to these external factors. The code may work just fine, however, the anticipated logic is flawed in someone else's perspective, whether an employer or a user or even yourself at some point down the line when you realize what you intented isn't really what's happening.

New features intermixing with older features will increase the likelihood of this happening. So more project management would definitely benefit in this case. Again, nothing wrong with new features. It's the agreed upon logic after the fact that will determine its effectiveness.

You need more human-power to manage it

Adding a feature or two to most projects usually does not cause any type of problem from a maintenance standpoint. Adding a dozen or so within a short time period, however, can be cause for alarm as resources begin to run low. And this is where the stress-level for developers usually begins to go up as the task/issue/bug list grows in size and when projects start to get abandoned.

So a good question to ask when thinking of adding new features to a project is "Who's going to be maintaining this?". Because undoubtedly, it will require work, even if minimal. If it doesn't require work, it probably means no one is using it, in which case you just spent a lot of time on a feature that didn't really need to be there. And regardless, will still need some form of maintenance.

It's always best to build within your current means. If you're a highly profitable company, then building more complex features that won't offset your bottom line is perfectly fine. But if you're a young up and coming startup and you keep continuously adding feature after feature, there will come a point where you won't be able to keep up with the time cost. So grow your codebase incrementally as your business grows as well.

Too many options for your users

From a user standpoint, fewer features are usually more useful. It's less overwhelming and fewer questions spring up in a users mind. Take any restaurant menu as an example. Would you rather have every option available traveling across a 10-page menu, or would you rather have 5 options but you know that each one is pretty fantastic. That's a personal choice of course, but I'd wager that many people would prefer the shorter more packed list.

But depending on your particular business, it could definitely turn into an overwhelming experience. If you look at some of the largest websites out there today, it's safe to say that they figured out the whole usability thing. Apps like Uber for example, which can be used with a single finger and take no more than 15 seconds to use offer essentially 1 single feature. As an example, if you had to scroll through a list of every single driver in your area and then read the reviews and choose one manually, you would be there for a while.

So fewer features are important if you have a specific thing that you want your users to do. Let's say you want them to click on a specific button on a page. If it's the only button on the page, it will have a higher chance of getting clicked, than if it was 1 of 10 buttons that all looked the same.

Coding in moderation is key

Like with everything and anything, it's best to take coding always in moderation. Too little and you won't build up enough momentum to attract users and to build something useful and too much and you're going to start to drown in it once the work catches up. And this is where project management and planning play a huge role.

Some of my best work has come from really deleting code instead of adding. It comes in the form of refactoring old projects or rebuilding legacy work. Sometimes making things simpler speeds things up in the future. In 2 months when that new developer walks through the door, he won't spend the first month battling with the bloated code, but will instead ease right on in with the neatly refactored and logical code. And the same will apply to you when you revisit your old cryptic code that you haven't seen in months.

There is nothing wrong with writing a healthy amount of code. I do it daily and almost hourly. But I balance out my features and improvements with deleting old unused code and refactoring what is already there. So it never becomes an overwhelming task to work on a project.