What is Feature Creep?
Feature Creep is the delay of and applications deployment due to unnecessary features, additions, add-on's and/or changes. Wikipedia even has an article on this:> Feature creep, creeping featurism or featureitis is the ongoing expansion or addition of new features in a product, such as in computer software.[1] Extra features go beyond the basic function of the product and so can result in over-complication rather than simple design. Viewed over a longer time period, extra or unnecessary features seem to creep into the system, beyond the initial goals.
-- WikipediaI started out programming as a hobbyist. I had multiple domains which ranged from a personal portfolio, a sandbox for development, a clan site for some games I used to play and others. The only time I actually finished a project was when I was on a deadline, with an extremely detailed workflow documented and agreed upon by the client. Staying focused may sound easy but it is very difficult to achieve and it often leads to code fatigue. Code fatigue is where you spend an abundant amount of time writing source code leading to the burnout of the logical flow or thought process. Code fatigue is much like writers block. What many people don't realize is that code fatigue leads to feature creep. A change of pace on your project is welcome when you are under a deadline, but that break in concentration can take you on a roller-coaster ride. Here are some tips on how to flow with your application development life-cycle, from start to finish.
Know Your Audience
The first step of white-boarding a project is knowing your end-user. Understanding who is going to be the first exposed to your application or project is a very important step. If you are launching an application for developers to manage contacts and invoices, you don't need to add a subnet calculator in its initial release. If you are designing an application for auditing network element configurations, you don't need to add an extension for graphing your results in the first release; tabular data is sufficient. Your users are the reason you are developing the app. They have a very specific need or want, and are requesting specific functionality. While working on the project, every time you get those, 'Ah-hah!' moments, write them down and save for later. They do not need to be included in your first launch, which cannot be stressed enough. Feature creep always starts out as a great idea, but ends up tormenting you.
Outline, Detail and Execute (ODE)
It pays off to wire frame and outline your app. One of the more common occurrences when feature creep occurs, is usually when there is no set-in-stone approach to developing. Some developers, such as myself, use this in a milestone based payment system. Applying a deadline to deliverables helps you stay on task. I use the philosophy of Outline, Detail and Execute.
- Outline - List what your goal is, list the steps needed to reach the goal, list all dependencies for each of those steps and a brief idea of how each step can be completed
- Detail - Create a modifiable proof of concept for each step you created in the outline
- Execute - Update your POC from the detail stage to support a development/production environment, framework, specific configuration
By staying disciplined in your work-flow you will ensure your focus is on what needs to be done, not what could be done.
Staying Focused
Feature Creep surfaces a lot of times when developers are fatigued with the instance they are currently working on. For example, bashing your head on the same 3 lines of code for 4 days can drive someone insane and kill off a whole bunch of brain cells. They start to think on how they can remedy the situation; they create an object or namespace as a remedy. They take that new focus and run with it for another three days unpronounced to them that the clock is still ticking. Use this as a rule of thumb: every time you face palm, take a 10 minute walk across the web.
Use this as a rule of thumb: every time you face palm, take a 10 minute walk across the web.
Taking your focus off the issue, but keeping it on the specific instance of your project will help more than hurt. That quick break from thinking, will reduce code fatigue and give you a chance to regroup your thoughts subconsciously. If you are still suffering after coming back to the task, reach out for assistance. I can personally guarantee that almost every issue you run into, someone else has as well, and documented it.
Understanding Your Applications' Flow
Keeping in mind your applications' internal flow will help prevent feature creep. Remember, there is a reason we have code revisions outside the need for security patches and bug fixes. Not every feature you want needs to be in the first release. Although it would be nice, it is not necessary. There have been a few instances where projects were launched, and the feature overload factor came into play. Too many options, too many choices. Check out this article from Smashing Magazine: Redefining Hicks Law. It goes a little more into detail about this subject. Here is another article from them as well, the easier the better.
Conclusion
Remember, Plan, Sketch, Do. Don't get off track, don't worry about the nooks and crannies. Don't let feature creep creep it's way into your daily routine. You can always go back and revise your code, launch it, and add feature sets. Not everything needs to be done at launch. Enjoy.
