YAGNI
In my opinion, YAGNI is one of the most misleading practices of eXtreme Programming because it can easily be used as an excuse by some designers to create simplistic and rigid design. Often, you will hear a bad YAGNI advocate tells you something like: “Logging framework? No, boy, System.out.println() works for me, that’s YAGNI”, “JUnit? System.out.println() can also work. See? That’s YAGNI”, or “An abstract class for shapes in my paint application? It sounds like premature generalization to me. I am a YAGNI fan, and I will not have an abstraction unless when the app supports a bunch of shapes” and on and on…
And when claiming this, they are missing the point of YAGNI. YAGNI does not mean sacrifice design principles for the ease of implementation and quick-fixes. YAGNI is not about implementing the easiest solution, but rather about implementing the simplest solution that could possibly work. And while, the easiest solution is, well, easiest, it often takes much effort to design the simplest workable solution. Practicing YAGNI means you need to practice the application of design principles, instead of staying away from them for thinking they are not necessary at the current time. While you do not want to implement a feature that is not currently required (nor you want to predict any potential feature), you want to have a design that is resilient to changes so that you will not be paying for reworking cost when actual demands appear. In the words of the pragmatic programmers, you want to make “reversible” design decisions, to cope with changes.
Back to the claims, I will use JUnit because it avoids me from coupling the code and its verification. It avoids me from reading the console to understand the outputs or spending most my time stepping through the code with a debugger. And I will use a logging framework if I happen to have a bunch of System.out.println() in my code - I do not care whether the client will ever want the system logs to be displayed, or written down to disk, or ever really care about them at all. I know that I can always quickly change the configuration settings to meet my client needs. Having only two shapes in the application? I will have an abstract class for them, the client code will interact with this abstraction instead of having some if/else checking. I do not care if the client will ever want to add a new shape nor do I care which shape that will be added, as I know I can adapt with it easily.
The bottom line, practicing YAGNI means that you do not fear of changes, and you do not have to predict the future. And that is enabled by a resilient design, the simplest workable design.
It is great, Buu. It is said that “You do not need to do now, but please do the good way that you can add easily later’, that is called YAGNI.
The article points out the erroneous thought of some designers in which YAGNI is conflict with Open-Closed principle. Actually, these two principles add values together. A highly effective level of OCP design would clear any misleading of YAGNI. With advanced level English the author expresses an excellent writing skill with a deep designing perception. I like examples of JUnit, abstract class, Logging Framework, etc… They persuade me significantly.
Hai, that summarizes it all
Phong, you’re right. OCP is a must for most designs. Unfortunately, many designers do not know about it, and even if they know about it, some, when practicing YAGNI, tend to stay away from it (i.e. “I do not need it now”)…