It tells that some features should NOT be developed with the thought that they will be needed in the future. The most common reason for developers to add features that they won't use at the moment is that they think that it will be easy to develop that feature at that time. The developer thinks: "This will be asked of me one day tomorrow. Then I don't need to change what I wrote." However, this feature is a supposing category as of the time of building and may never be requested from you. At this point, some may argue that this is planning and that such improvements can be made as a result of good analysis. However, real-life experience is far from this, and developers have to bear the cost of developing hypothetical features they predicted incorrectly. The analysis, programming, and testing time spent on this feature is wasted.
Let's say we add a concurrency system to our project. We added concurrency for all I/O processes. If it isn't a critical requirement at this point, YAGNI says "DO NOT". So why?
You won't need to do this and you'll have wasted your time, which will not only complicate your code even more. Imagine that we guessed right and we would really need that feature. Even in this case, this supposing has serious costs for us. First, we delay some of the things we need to do today while we are doing this feature that we think will be needed in the future. So this supposing brought us latency costs. Considering that only one-fourth of the features developed according to the research is really useful, delaying an already necessary feature on assumptions is an action that needs to be reconsidered.
In the case we guessed correctly, the delay cost is not the only cost. Transport cost is also one of the most important problems. We will have to move the code for this feature, which we will use in the future, in our project. With all changes, we need to change that part of the code as well. This code snippet, which we have never used at the moment, may cause errors. During debugging, we need to debug that part as well. In summary, we pay the cost of each line of code added to the project for the lines added for this feature. However, if we had added this feature to the project later, we would not have had to bear this cost during this period.
The issue of when the YAGNI principle applies is somewhat relative, but it can be said briefly as follows: As the size of the feature we assume, the importance of the YAGNI principal increases. If a few-hour job is to be done and this will cover a few days' developments in the future, it may not be a problem, but the longer this period, the higher your risks.
Solve Today's Problem, Not Tomorrow's
These features we've developed will require additional testing effort, documentation, and subsequent maintenance considerations. When we say let's make a tricky software with additional features, the possibility of developing a more complex and more complex software increases. Therefore, it is always beneficial to avoid developments that are not specified as needed. If we doubt some additionals, we can ask ourselves the following questions.
- 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 suddenly. One of the problems with this is that statements about the future are mainly 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.
To Sum Up
YAGNI is a principle that says not to include things we don't need in the system. It is quite similar to KISS from certain points. During the development phase, we sometimes act predictably(?) and write classes and methods that we think may be needed in the future. This is due to both the foresight that we may need in the future (?) and the fact that we want to see our development bigger.
Top comments (0)