The non-functional-no-value trap

This post is about another “evergreen” in IT: The fallacy that only business features have business value.

You think this is not a fallacy? That only business features have business value?

Well, you are not the only one. I meet such persons quite often, especially if I work in an architectural context. There, the project managers (non-agile flavor) or product owners (agile flavor) often claim that non-functional requirements do not create business value and thus need to be prioritized down, postponed or dropped completely.

If these people are particularly obstinate, I sometimes answer:

“You are right. Let us forget about all those worthless non-functional requirements!

First, let us forget about availability. All this availability crap just costs money without creating any value! Who needs all this expensive hardware, redundancy and fail-over? Let us just buy a discounter PC and place it under your desk. If the application should crash, you can simply reboot the PC the next time you are in the office. So much cheaper! As you just said: Availability has no value!

And caring about scalability and response times is also just plain waste! Who cares if response times go through the roof if more than a handful of users try to access it at once? You are right: Worthless! Let us drop it.

And all that security crap! Complicated mess without any value! Let us get rid of it! Why bother with logins, data security, privacy and all that nonsense? Only makes things unnecessary complicated and gives us a headache! We can implement so many more valuable business features if we can ignore all that useless nonsense!

I am totally with you: Let us all hack business features as fast as we can without these pointless non-functional requirements slowing us down. Perfect! I am ready for it! Tell me what to do!

The only demand I have: When the application goes live, I will be on vacation and the hotline will get your mobile phone number if unexpectedly there should be any problems. But I am sure that is no problem for you. What could possibly go wrong?”

As I wrote, this is the answer for the obstinate cases. I firmly recommend delivering the message in a nicer way, if it is possible, especially omitting the sarcasm. I also do. Most people respond better if you deliver the message without sarcasm.

Sarcasm is reserved for the obstinate cases only, to drag them out of their “auto-pilot” habits.

NFRs create business value

I only used the sarcastic version here because it makes the point very clear, that there is a problem with the “only business feature have business value” claim:

• Availability – If your application does not work at all, you do not create any value.
• Scalability – If your application becomes unbearably slow under load, you create a lot less value than you could. Additionally, you will lose customers, i.e., create even less value over time.
• Security – If your application is insecure, leaks personal data or worse, you will put off and thus lose customers. It can even have severe legal consequences – quite the opposite of creating value.

These were just the NFRs (non-functional requirements), I mentioned in the example above. There are a lot more NFRs that prevent you from creating business value or even destroy value if not satisfied (see, e.g., here for an overview over NFRs).

Overall, it can be said that NFRs:

• Either are a prerequisite for creating value (e.g., availability)
• Limit how much value you can create (e.g., scalability)
• Destroy value if not satisfied (e.g., security)

If you ponder the fact that not satisfying NFRs reduces the business value you create, you can invert the observation:

Non-functional requirements (NFRs) have business value.

You create more business value, make more money, satisfy more users, if you properly satisfy the given NFRs. It is that simple.

You can even calculate a business case for each NFR: How much money will you not make or lose if you do not satisfy the respective NFR? This gives you an upper limit for the budget you have to satisfy it. ¹

In the end, an NFR is nothing but the derivation of a stakeholder’s need or demand. E.g., availability describes the user’s demand to be able to interact with the application at any time they want. Scalability describes the demand to be able to use the application in a good way no matter how many other people use it at the same time. And so on.

Missing knowledge

This raises the question: If NFRs also have business value, if you even can calculate business cases for them, why are they so often ignored? Why is the “only business features have business value” fallacy so widespread?

Based on my observations, it is primarily due to missing knowledge. For the last 30 years or more, IT project budgets belonged to the business departments. Thus, they had the say what the money was spent for.

And what do you spend your money on? You spend your money on things whose value you can evaluate. And you can only evaluate the value of things you understand.

The problem is that most people on the business side do not really understand IT and software development. If you try to discuss topics like redundancy, fail-over, eventual consistency, OS idiosyncrasies, browser particularities, encryption algorithm vulnerabilities, etc., they are lost.

To be clear: It is okay that they are lost. They are business domain experts, not IT experts. There are even a lot of people in IT who are lost with quite some of the aforementioned topics. How should business experts not be lost then?

But these are the topics that are relevant in the context of implementing NFRs. Business domain experts cannot evaluate these topics. They cannot evaluate different solutions options. And from a purely technical perspective they even cannot evaluate the business value of the respective NFR.

And what is the typical reaction if you cannot evaluate something at all? You tend to ignore it. You try to push all decisions away from you because you are overstrained with making a decision. You tell the software development team: “I do not care. It is your job to make sure these things work.”

Additionally, as you do not understand the topics, as a budget owner you ignore them in the budget allocation process. Because you do not understand their value, you refuse spending money for them, which leaves the software development team with the responsibility (“It is you job to make sure these things work.”) but without a budget to take care of it – probably a familiar situation for many of you.

This is the biggest driver for the trap, I have experienced – everything else imo is mostly an evolution of this initial driver over time.

Disarming the trap

Still, a fallacy is a fallacy, and this is a fallacy that often creates a lot of harm and destroys value.

Therefore: What can we do to disarm the trap, to get rid of the fallacy?

As so often, I think it is our job as IT experts to help the decision makers evaluating the options and making the right decisions.

In this context it means:

• We need to help them understand first that NFRs have a value.
• We need to help them understand the business value of a NFR in their language. Talk business, not technology! Talk needs and demands of stakeholders, talk money and risks, not IT jargon.
• We need to provide them with solution options, explain them the costs and the trade-offs (in business language). Do not forget to include not doing anything as an option to make clear the consequences of the “let’s not do it” decision.
• We need to support them to make the decision. We need to answer their questions (again: In their language), help them to play with the options, tweak them, understand the consequences, and so on to come up with a decision.

We cannot expect a business expert to become an IT expert over night. IT is hard, and especially the topics that are typically touched by the NFRs are hard.

We can only expect them to understand that NFRs have a value – often after we helped them first gaining this understanding. And then we need to support them in making the right decisions, in balancing functional and non-functional requirements and investing the budget where it creates most value.

This is our job: To enable them, to support them, to help them shine and deliver the best solution possible.

When to work on NFRs

If we were successful on that job, if the budget owners have allocated budget for working on NFRs, we need to work on them and make transparent to the budget owners how and when we spend their money. This raises the question: How and when to work on NFRs best?

Especially, in the Agile community there is still a lot of – sometimes fierce – discussion when to address NFRs and to do the required architecture and design work:

• Do they need to be addressed upfront?
• Are NFRs dedicated user stories (assuming you are doing the predominant Scrum)?
• Are they tasks that need to be implemented to complete a user story?
• Are they part of the “definition of done” (DoD)?
• Or do they magically emerge from an endless series of tiny TDD loops?
• And so on …

My personal answer is: It depends.

Not because I have worked as a consultant for too long, but because it really does:

• Some NFRs require some thinking upfront to come up with a suitable design before starting the implementation.
• Some can be treated like a regular user story, i.e., be implemented en bloc.
• Some need to be touched multiple times in different places. Depending on their particularities it can be useful to either turn them into tasks or make them part of the DoD.
• For some of them the underlying design principles are so familiar to every single developer in the team that you can rely on having them implemented as part of the TDD loops.

So: It depends.

I personally think that common sense should be a good guide when to do what. Yet, common sense can be a slippery slope at times. If you do not want to rely on it, you can still refer to a lot of articles and books that have been written about the topic. Thus, I will not dive deeper here.

The key point is: You need to address NFRs and there is a place for it, no matter which process model you use. Find your way. Do it. And make it transparent to the budget owners.

But keep in mind: All considerations when and how to work on NFRs are pointless as long as the budget owners have not understood that NFRs have business value.

Thus my advice: Make sure the budget owner understands the business relevance of NFRs, help them understanding the costs, benefits and trade-offs of the different options and support them in making the right decisions. The rest will usually fall in place.

Moving on

We discussed that NFRs also have business value because you lose value – or even actively destroy value – if you neglect them. It is also possible to calculate a business case for NFRs the way can calculate it for functional requirements.

Still, the business value of NFRs is often neglected, usually because of a lack of knowledge of the budget owners in the projects. Thus, our most important job in that context is to help them understand that NFRs have business value and support them in making the right decisions to maximize value for the overall project. The rest is “just work”.

I hope this post will help you the next time you meet someone who is convinced that “only business features create business value”, that you will have the arguments at hand required to make that person reflect their position.

And then, make sure to support that person in making the right decisions. It does not only help them. It will also improve your situation and situation of the whole team a lot. If this is not worth it …