Do we really need this feature?

A story about two features in two different software programs

What is the nice thing about developing software?

You can define what you want. You define the features that you need or that you would like to have. You prioritise requirements and thus determine what is more important to you and what you may want to receive first from your development partner. You look at intermediate results and provide feedback at an early stage so that you get exactly what is most useful for your employees. Of course, all of this costs some money, but in the end you get a result that is worth the money.

And what is the most unpleasant thing about software development?

You have to define what you want. And you have to do it in such a way that your development partner really understands what you need. For example, correct, complete, unambiguous, consistent requirements. You have to provide feedback so that your employees get features that are easy to find and use. And you have to do that even when you don’t really have time for it because something else is bothering you. And of course it all costs money…

Many companies use service providers or agencies to develop software. For them, it is simply a good opportunity to get something that is not available anywhere else: a tailor-made solution that offers one or more services and thus makes it much easier for users to work. At a price at which they cannot or do not want to produce it themselves. Ideally from a partner who can put themselves in the company’s shoes and understand what it needs.

This is the story of two features in two different software programmes.

Mr Meyer has left the company

Some time ago, a friend told me a story. He and his company had taken part in a tender. Hundreds of requirements filled countless pages. For each requirement, the client wanted to know whether the supplier’s product met the requirement and how it worked. We want X, how does your solution support that? We need Y, how can you capture Y? Then came the question about Z. Unfortunately, Z didn’t work with the tool. At best, it worked with thinking outside the box and turning a blind eye.

What should my friend do? What would you have done in his place? Would you have cheated on the answer? Or would you have written the truth and risked being thrown out of the tender at this point? And what would you have expected in the client’s place?

Together with his colleagues, my friend decided on a favourable description of the feature that would solve Z. It turned out as it had to: the second round was reached. The presentation was due. Of course, Z would also be discussed. How should one react? Admit with a wink that you didn’t tell the whole truth? Explain that you understood Z differently than it presents itself here and now? Or explain that you might not be able to support Z the way he needs it at the moment, but that this will be possible very quickly in the future?

A, B and C were discussed with the client. X and Y too. Now Z was next. And my friend said: ‘Z is an interesting feature that we have discussed at length. We have different opinions about what exactly you want to achieve with it. Who needs this feature from you?’

The participants from the company that had issued the request looked at each other. They looked left, they looked right. Who needs this feature? Not me! You? Then one of the participants said: ‘I think that was a requirement from Mr Meyer. Mr Meyer left the company three weeks ago. I don’t think we need the feature anymore.’

YAGNI

Let’s take a small leap into the world of software development. There you will find many principles and practices that make development significantly easier. One such set of principles and practices is defined by so-called clean code development.

• Clean code refers to code that is easy to understand, modify, expand and maintain.
• Principles are guidelines for structuring software. They complement each other. If software is developed contrary to the principles, the effects will become apparent in the medium term at the latest, for example, through increasing efforts for adjustments.
• Practices are instructions for action, i.e. methods and techniques that are used continuously.

YAGNI is a principle. As an acronym, it stands for ‘You Ain’t Gonna Need It’. It addresses software developers who like to think ahead and program additional functions, assuming that they will need them at a later point in time.

There are a number of reasons why developers implement features that are not needed today:

• Developers are always faced with the dilemma of either implementing exactly what is specified or thinking outside the box and laying the foundation for something that will come in the future. (Similar to a car: a car will most likely never need 5 tyres at the same time to drive. Nevertheless, it can make sense to provide space for a spare tyre in the boot. [1])
• Developers want to surprise the client with functionality. [2]
• Developers enjoy designing an architecture that is prepared for possible future requirements.

Another reason for deviating from YAGNI lies in requirements engineering and management. The better the requirements management works, the less effort is required to deal with ambiguity, incompleteness or interpretation.

Problems with unused features

Back to Mr Meyer and the tender. At the time of the tender, no one at the client company could have foreseen that Mr Meyer would be leaving the company soon. Nevertheless, companies must repeatedly ask themselves the question of who needs what and why. Of course, software is patient and of course, as a service provider, you can program X, Y and Z. And exactly X, Y and Z according to the YAGNI principle. [3] However, software development costs money and it makes sense to offer users the greatest possible benefit. If only one person needs a feature, a client can certainly decide internally whether it would be better to commission another feature that would benefit several users.

At the beginning of this article, I promised to tell you a story about two features in two different software programs. I have already told you about feature Z. Even though it is unclear what Z actually does, it is relatively clear that (almost) no one in the client’s company will use Z. It’s a shame, really. Individually specified, individually ordered, individually programmed. Money down the drain.

Let’s move on to the second feature of my announcement. Feature A lives in a standard program, e.g. MS Excel. It is one of 10,000 other features. You use it just as little as 99 percent of the other users of the program. Does that bother you? Probably not, because like most users, you only use a few of the standard program’s functions. Standard does not mean that everyone uses all the functions, but that certain functions are included in the program by default. You didn’t have to do anything for it, you didn’t have to explicitly order it and you didn’t have to explicitly pay for it. But you did have to pay for it implicitly. And possibly not just once when you bought the software, but on an ongoing basis through the maintenance and service contract that you signed up for. It’s a shame, but in the general context of standard software, it’s also somewhat negligible in practice. [4]

So now we have two features: Z and A. Neither is used. Both are paid for directly or indirectly, explicitly or implicitly. With feature A, you can do practically nothing – it is part of a standard software [5] – but with Z you can. Here you have the opportunity to apply YAGNI yourself. Here you have the opportunity to use a defined process in requirements management to determine the requirements and features that will really bring you the best possible benefit. And you know what the nice thing about that is?

Yes, no, maybe

Do you remember the very first question at the beginning of my post? What is the nice thing about developing software?

Software development is usually not a one-time thing. Yes, you have a need and define and prioritise requirements. You go looking for a development partner and choose one. You work together and sometimes there are disagreements in the course of the collaboration. [6] But the nice thing is: you use software that has been developed for your situation. It brings advantages to your employees. It can do something that was previously not possible or only with difficulty. And over time, everyone involved becomes wiser.

And why is that a good thing? Everything ages. Software too. At some point, you may find yourself in a situation where you have to refurbish or even completely modernise a piece of software. Software modernisation means adapting software to new requirements and technologies in order to improve its performance, security and user-friendliness, reduce costs and complexity, and increase its lifespan, scalability and flexibility. And software modernisation means asking yourself again whether you really need feature Z. Has it fulfilled the purpose you originally hoped for? Was it used as intended or has the context shifted and Z has become unnecessary? So you have the opportunity to ask yourself the following question for each feature in the course of a software modernisation: Do we really need this feature? Yes, no, maybe?

If the answer is ‘yes’, modernise feature Z. You needed it earlier, you need it now, great. If the answer is ‘no’, simply leave it out. Situations change, so take the opportunity to simply leave out the unnecessary. And if the answer is ‘maybe’, go back to the internal coordination, get opinions and weigh up which feature might be useful instead. Isn’t that nice?

Notes:

If you like the article or want to discuss it, please feel free to share it with your network.

[1] This non-technical example also illustrates the dilemma of forward-looking implementation: Of course it makes sense to have a way to replace a flat tyre in the event of a puncture. But does it have to be a spare tyre, or would a gas mixture that makes the tyre roadworthy for another 50 kilometres, so that the next petrol station or garage can be reached, perhaps be enough? Ergo: arbitrary decisions by software developers should always be treated with caution. When in doubt, the requirements should be specified as precisely as possible and checked for completeness.

[2] This is also known as gold plating.

[3] As a software development service provider, we at t2informatik also try to understand the motives behind a feature. If we understand the motive, we are ideally able to discuss different solutions that can then be coordinated to achieve the best possible result for the user.

[4] The unused functionality of a standard solution is usually ignored; however, if the total of unused functions is very large, companies might consider opting for smaller solutions from which they can use more functions, ideally for a little less money.

[5] It would be interesting to see how Microsoft reacts when you tell them that you don’t need the function in MS Excel to merge the contents of different cells, where you only want to take over the values and not the underlying formulas, and you want to know how high a possible discount would be.

[6] Software development is a great thing, but it is not that easy, and I don’t even mean the programming itself, but the communication between people. Differences of opinion in projects are therefore relatively normal to a certain extent. It is important that you still work together to find the best possible solution. Perhaps you could talk to us about your situation and how we can implement your wishes and ideas.

Michael Schenkel has published more posts on the t2informatik blog, including:

t2informatik develops and modernises software as a service provider. Click here to learn more.