Feature creep is one of the most prevalent anti-patterns in my experience. I personally find it a recurring challenge to avoid. The issue is that we can always find features that are nice to have with our solution. That makes them very attractive to tack on to our release or version. There is also a limit to what can be called feature creep. Let’s look a little deeper into this one.
Defining the Feature Creep Anti-Pattern
Scope creep is incredibly common as an anti-pattern, and Wikipedia gives a helpful, concise definition. [Click Here to See The Page]
“Feature creep is the excessive ongoing expansion or addition of new features in a product,[1] especially in computer software, videogames and consumer and business electronics. These extra features go beyond the basic function of the product and can result in software bloat and over-complication, rather than simple design.“
Notice the modifiers in the text above. When you see words like excessive, it always begs the question of what that means. Unfortunately, scope creep is a sort of dark art. We want to strike a balance between adding features that are worth the cost without blowing past target dates. This brings us back to the challenge of knowing when to declare victory. However, with feature creep, we can get ourselves into a situation where we are forced to go forward instead of cutting scope.
Less Is More
The way to beat this anti-pattern is to focus on the truism that something is better than nothing. Thus, a product with fewer features is better than one waiting for one with more features. There is always a minimum viable product that needs to be released. However, the challenge arises when you add to that MVP. The ROI for additional features can be tricky to calculate. The complexity is that it is not an either-or situation. It is often a now-or-later decision to be made. That is where I find we can best argue for or against a scope change. The decision comes down to whether we need the feature now and cannot wait until later.
Unintended Consequences
All scope creep is not an instance of this anti-pattern. There are changes we can make that are done so in an intentional manner with the trade-offs duly considered. However, any change should be drilled into to ensure the costs are appropriately measured. There are all sorts of side effects that even small changes can trigger. The best way to approach any change is to have a template of things that are potentially impacted by a change and use that as a checklist. If you miss something, then add it to the list for the next time. Here are a few to start you off.
- Testing
- Documentation
- Application Flow
- Additional/Changing Security Requirements
- Data models and Back-End Impact
- Application Performance
- End User Cost
This is not a comprehensive list, so spend some time thinking about the impact you have seen changes make. If you do this regularly, then you may find the feature creep anti-pattern to be one that fades into the distance.
