Do we really need more features?
Adding features adds complexity to our program. Is this new feature really worth it? We should be asking this question more often.
I was listening to an interview with Mary and Tom Poppendieck on Mob Mentality. Mary had some very interesting thoughts about adding features.
Mary starts by making a very simple observation. As projects grow larger they inherently get more complex and that complexity makes it harder to manage the code and harder to add new features. Adding features gets in the way of adding more new features. In that light, simply adding more features is not the answer. We need to actually prioritize the features we are adding. Every low-priority feature we add, makes it harder to add a higher priority feature later, therefore we need to make sure that every feature we add is a high priority feature.
As developers, we often have our heads down in the code. We are often thinking about structures and architectures. We are always thinking about how to structure our code so it is easier to add more features. There is this inherent sense that adding more features is adding more value to our project. We get so caught up in the details of how to add those new features, that we often fail to ask ourselves why we are adding them to begin with.
Prioritize your work
I liken features to items on a checklist, in fact, many issue tracking tools look a lot like checklists. The problem is there is often no priority. A checklist without priorities is a recipe for disaster. Human nature is to pick the easiest ones and knock those off first, but often those don’t really move the needle. So at the end of the day, we check off a lot of boxes, and feel really good about ourselves, but what have we actually accomplished? If we are just adding features without any priority, we’ve created a bloated mess full of unimportant features and made it harder to add the important ones.
Involve Your Customers
We need priorities, but where do they come from? The ultimate priority setter should be your customer. They are the ones paying the bill and they are the ones using the product. We need to make sure that we get them involved and that they help set the priorities. Now that doesn’t mean we as developers don’t get a say. Sometimes there may be a feature that is an enabler for another higher priority feature. In those cases, technical concerns might dictate adding the lower priority feature first. But the key is that the customer has input and is the ultimate driver.
Reprioritize Often
As the project goes on, you and your customers are learning more about the problem. Priorities may change. You need to meet with your customers often, in order to reset the priorities and make sure you are always working on the highest priority item.
Normalize Removing Code and Deprecating Features
Along these lines, we should also normalize removing code. Anything that makes our codebase simpler and easier to understand should be encouraged. It will make it easier to add those high-priority features in the future. Along with that, we should not be afraid to deprecate features that aren’t being used. Determining if a feature is used or not requires some sort of observability and/or very close coordination with the customer. If a feature is not being used, it is just cruft that prevents us from adding new higher-value features.
