Posted on

Feature creep is a function of human nature – how to combat it

When we develop tech products, we are always interested in how to improve them. We listen to customers’ requests based on what they need, and we come up with ingenious new features we are sure that they forgot to request. Either way product development inevitably becomes an exercise in what features we can add in order to improve the product. This results in feature creep. 

The negative side of adding features

Adding new features to a product does frequently increase utility and therefore improves the product. But that does not mean it is purely beneficial. There are a number of adverse effects of adding features that are sometimes being downplayed.

The addition of each new feature adds complexity to the product. It is one more thing to think about for the user and the developer. What is worse is that unless this feature is stand alone and not related to any other features it does not just increase complexity linearly but exponentially. For example, if the addition of a choice in a drop-down menu has an effect on other choices being available in other drop-down menus the complexity increases at the system level not just with the new choice but with all the combinations. The consequence is that the entropy of the system is increased significantly. In practical terms this means that more tests need to be done, troubleshooting can take longer, and general knowledge of system behavior may disappear when key employees leave unless it is well document, which in turn is an extra cost. 

The risk also increases based on the simple insight that the more moving parts there are the more things can break. This is why for decades I have ridden only one gear bikes. Because of that I don’t have to worry about the gear breaking or getting stuck in an impossible setting. Every new feature added means new potential risks of system level disruptions. Again, this is not a linear function as interactions between parts of a system add additional risks that are difficult assess. I think many of us have tried adding a function in one part of the system that produce a wholly unforeseen effect in another part. This is what I mean about interaction. 

Every new feature requires attention, which is always a scarce resource. The user has a limited attention gap and can only consider a low number of options consciously (recent psychological research suggests around four items can be handled by working memory). Furthermore, the more features the longer it takes to learn how to use the product. And this is just on the user side. On the development side every feature needs to have a requirement specification, design, development, documentation and maybe training material needs to be made. 

How about we don’t do that? 

Luckily, it is not the only way to improve a product. We can also think about taking features away but somehow that is a lot harder and rarely if ever does it enter as a natural option into the product development cycle. It’s as if it is against human nature to think like that. 

In a recent paper in Nature entitled “People systematically overlook subtractive changes”  Gabrielle S. Adams and collaborators investigate how people approach improving objects ideas or situations. They find that we have a tendency to prefer looking to add new changes rather than subtract. This is perhaps the latest addition to the growing list of cognitive biases identified in the field of behavioral economics championed by Nobel laureates like Daniel Kahneman and Richard Thaler. Cognitive biases describe ways in which we humans act that are not rational in an economic sense. 

This has direct implications for product development. When developing a tech product, the process is usually to build a road map that describes the future improvement of the product. 99% of the time this involves adding new features. Adding new features is so entrenched in product management that there hardly is a word or process dedicated to subtracting features. 

However, there is a word. It is called decommissioning. But it has been banished from the realms of flashy product management to the lower realms of legacy clean up. As someone who has worked in both worlds, I think this is a mistake. 

How to do less to achieve more

As with other cognitive biases that work against our interest, we need to develop strategies to counteract them. Here are a few ways that we can start to think about subtracting things from products rather than just adding them. 

Start the product planning cycle with a session dedicated to removing features. Before any discussion about what new things can be done take some time to reflect on what things can be removed. Everything counts. You don’t have to go full Marie Kondo (the tidy up guru who recommends throwing away most of your stuff and who recently opened a store so you can buy some new stuff ) though, removing text, redundant functions is all good. A good supplement for this practice is analysis about what parts of the product are rarely if ever used. It is not always possible for hardware products, but for web-based software it is just a matter of configuring monitoring. 

Include operational costs in the decision process, not just development costs. This is not an exact science like anything in product development but some measure of what it takes to operate new features is good to put down as part of the basis for a decision. If a new feature requires customer support, then that should be part of the budget. Often a new feature will lead to customer issues and inquiries. That is part of the true cost. Also, there may be maintenance costs. Does it mean that a new component of the tech stack is introduced? That requires new skill, upgrades, monitoring and management. All of this needs to be accounted for when adding new features.

Introduce “Dogma Rules” for product development. A big part of the current international success of Danish film can be ascribed to the Dogme 95 Manifesto by Palme D’or and Oscar winning directors Lars Von Trier and Thomas Vinterberg. It was a manifesto that limited what you could do when making films. Similarly, you can introduce rules that limit how you can make new product enhancements. For example, a feature cap could be introduced or the number of clicks to achieve a goal could similarly be capped. 

Create a feature budget. For each development cycle create a budget of X feature credits. Product managers can then spend them as they like and create x number of features but by having a budget, they can also retire features in order to gain extra credits. Naturally this runs inside the usual budget process. Obviously, this is somewhat subjective, and you may want to establish a feature authority or arbiter to assess what counts. 

Work with circular thinking. Taking inspiration from the circular economy, which has some similar challenges is another approach. Rather than only thinking about building and removing things it could prove worthwhile to think in circular terms: are there ways to reuse or reappropriate existing functionality? One could think about how to optimize quality rather than throughput. 

Build a sound decommissioning practice. Decommissioning is not straight forward and definitely not a skill set that comes naturally to gifted creative product managers. Therefore, it may be advantageous to appoint decommissioning specialists, people tasked primarily with retiring products and product features. This requires system analysis, risk management, migration planning etc. Like testing, which is also a specialized function in software development, it provides reduction in product risk and cost.  

Taking the first step

Whether one or more of these will work depends on circumstances, what is certain is that we don’t naturally think about how to subtract functionality to improve a product. We should though. The key is to start changing the additive mentality of product development and start practicing our subtractive skills. It is primarily a mental challenge that requires discipline and leadership in order to succeed. It is bound to meet resistance and skepticism but most features in software today are rarely if ever used. Maybe this is a worthwhile alternative path to investigate. Like any change it is necessary to take the first step. The above are suggestions for that.

Posted on

Meditation #3 Five Theses on IT Security

The point of IT security is not to keep everything locked up. The reason we often think about security like that may be our day-to-day concepts of security. For example, maximum security prisons where particularly dangerous criminals are being kept. Keeping them locked up may be a comforting idea. However, we would probably squirm at the thought of maximum-security supermarkets, where only prescreened customers could get in for a limited. A high level of security is good but obviously it doesn’t work for all aspects of our society. Security needs to be flexible. We need a clearer understanding of what security is. Here are five theses on security that describe that. 

Thesis 1: “Security Is the Ability to Mitigate the Negative Impact of a System Breach”

 The consequence is that understanding what these impacts could be is the first step, not finding out what security tools can do and how many different types of mitigation you can pile onto the solution. Understanding potential negative impacts comes before thinking about how to mitigate them. If there are no or only small potential negative impacts of a system consequently no or little mitigation is necessary in order for the system to be secure. 

Thesis 2: “Mitigation Always Has a Cost” 

 Security never comes for free. It may come at a low cost and the cost may be decreasing for certain types of mitigation over time, but it is never free. What’s more is that much of security costs are hidden.

There are three primary types of mitigation costs: economic cost, utility cost and time cost. The economic cost is capital and operational costs associated with mitigation. These include salary for security personnel, licenses and training. Usually, they are well understood and acknowledged and will be on budgets. 

Utility costs arise when a solutions utility is reduced due to a mitigation effort. This is the case when a user is restricted in accessing certain types of information due to their role. A developer may want to use production data because it is easier or wants to perform certain system functions that he or she might otherwise need someone else to do. Full utility is only achieved with full admin rights, reducing those privileges as part of a security effort reduces utility. 

Time costs arise when a mitigation effort increases the time spent to achieve an objective. For example, two factor authentication or the use of CAPTCHA are well known examples of time costs but approval flows for gaining access and authorizations in a system are other examples of time costs.

Only the first type is typically considered when thinking about security costs, but the others may exceed the economic costs. This means that security carry large unknown costs that need to be managed.

Thesis 3: “You Can Never Achieve 100% Mitigation with Higher Than 0% Utility” 

The only 100% secure solution is to unplug the server, which of course renders it useless. It only becomes useful when you plug it in but then it has a theoretical vulnerability. If the discussion is only centered around how to achieve 100% protection any use is futile. The consequence of this is that the discussion needs to turn to the degree of protection. Nothing is easier than dreaming up a scenario that would render current or planned mitigation futile but how likely is that. We need to conceptualize breaches as happening with a certain probability under a proposed set of mitigations. 

Thesis 4: “Marginal Risk Reduction of Mitigation Efforts Approach Zero”

The addition of each new mitigation effort needs to be held up against the additional reduction in the probability of a system breach or risk. The additional reduction of risk provided by a mitigation effort is the marginal risk reduction. When the marginal risk reduction approaches zero, additional mitigation should be carefully considered. Let us look at an example: If a service has no authentication the risk of a breach is maximal. Providing basic authentication is a common mitigation effort that will reduce risk significantly. Adding a second may provide a non-trivial reduction in risk but smaller than the first mitigation. Adding a third factor offers only a low marginal reduction in risk. Adding a fourth clearly approaches zero marginal reduction in risk. For some cases like nuclear attack, it may be warranted; for watching funny dog videos, maybe not. 

Thesis 5: “The Job at Hand Is Not Just to Secure but to Balance Security and Utility” 

Given that mitigation always has a cost, and the marginal risk reduction of additional mitigation efforts approaches zero, we need to reconsider the purpose of security. The purpose of security should therefore be reconceptualized from optimal protection to one of achieving the optimal balance between risk reduction, cost and utility. Finding that balance starts by understanding the nature and severity of the negative impacts of a system breach. While costs of mitigation continue to drop due to technological advances the full spectrum of costs should be considered. Preventing access to nuclear launch naturally needs top level security, but a blog about pink teddy bears does not. For every component we have in the cloud we need to make this analysis in order to achieve the right balance, not to live with too high risk and not spend unnecessarily to reduce an already low risk. At the same time we need to keep our eyes on how mitigation efforts impact the utility of the system so as not to unnecessarily reduce the usefulness.