What is the YAGNI Principle?
YAGNI Principle – only implement features that are really needed
The YAGNI Principle is a key concept in software development and stands for “You Ain’t Gonna Need It.” It serves as a guideline for developers to avoid the temptation of over-engineering by anticipating future requirements. Often, developers may think ahead and build additional features under the assumption that these will be useful at a later stage. However, this proactive approach can lead to unnecessary complexity, wasted time, and increased maintenance efforts.
The YAGNI Principle was developed in the context of Extreme Programming (XP) and demands to stop this common practice and to implement only those features that were actually needed, discussed or commissioned.
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:
The best process in requirements management
Factors of software acceptance
Documentation in code – pros and cons