What is the YAGNI Principle?

Reasons for the deviation from the YAGNI Principle

There are a number of reasons why developers implement features that are not needed today. One reason for the deviation from YAGNI lies in requirements engineering or requirements management. The better the requirements management works, the less effort is required due to ambiguity, incompleteness or interpretation. Otherwise the following can easily happen:

• Developers interpret requirements and implement more than is specifically required. Possibly missing requirements or requirements are described inaccurately, so that developers decide situatively which features still have to be implemented.
• In order to be able to implement future requirements as easily as possible, features are implemented as generically as possible. Especially in a volatile environment with frequently changing or new requirements, this can be observed regularly. Flexibility is the keyword here.

There are also a number of other reasons that contribute to the deviation from the YAGNI Principle:

• Developers want to surprise the client with functionality they don’t expect. This is also known as gold plating.
• Developers have time that they may not have in the future.
• Developers enjoy designing an architecture that is prepared for future requirements.
• Developers hope to gain advantages in areas such as testing and continuous delivery.

The YAGNI and KISS Principles

The YAGNI Principle and the KISS Principle complement each other. The KISS Principle – Keep It Simple and Stupid – looks for the simplest possible solution to a problem. “Everyone can do complicated”, but the art lies in the simplicity of a solution. The YAGNI Principle complements KISS by asking the question “do we really need this” and thus steering the answer in the direction of avoiding effort. So it can happen for example that

• no patterns are implemented,
• no libraries are used and
• no deployment processes are automated.

Nevertheless, it can of course make sense to answer a question about “do we really need this” with “yes” as well. Ideally, this should be discussed and agreed with the team, the product owner, the project manager, the product manager and, if necessary, the customer. And of course it also happens regularly that development teams become smarter in the course of a development and say to themselves, “If we had done it differently back then, it would work faster and easier today”. This can result in expenses and costs in the form of refactorings. However, this can never be a request to implement features on “suspicion”.

Factors in the YAGNI Principle

Which factors or questions are there in the course of the YAGNI principle that support developers in making the right decision? Here is a selection:

• Is it 100% sure that the implementation is needed?
• What are the investment costs?
• How long does the implementation take?
• What are the opportunity costs?

Often such questions cannot be answered immediately. One of the reasons for this is that statements about the future are fundamentally difficult and cannot be easily quantified. This is another reason why it makes sense to coordinate with colleagues and make a good decision together. In agile developments, for example, Sprint Planning 2 can be used.

Advantages of the YAGNI Principle

If only those requirements are realised which have to be implemented clearly, there are some advantages:

• A feature creep is avoided.
• No bloatware is created, i.e. software with functions that are hardly used or not used at all.
• Functions that are not implemented do not have to be tested, documented and supported. Thus there is no (unnecessary) effort.
• The profit increases, because the effort for the implementation of allegedly needed functions is eliminated.
• The code base remains “leaner” and is therefore easier to maintain.

Notes:

When using the YAGNI Principle, the combination with other principles and techniques such as refactoring, automated testing and continuous integration can be used.

Here you can find additional information from the t2informatik Blog:

What does t2informatik actually do? One click and you'll know.