I have read it from here . It is the reminder that developer/designer should never add functionality until it is necessary. In fact, the project usually face the situation:

• Designer/TA usually think up-front architecture. They try to guest potential architecture requirements as much as possible. Some of they happy to become a predictor that can guess the client's mind even to next ...10 years!
• Developer try to keep their property along with project life-cycle. When the requirements is changed, the code is changed. Many developers will modify existing code base or add new methods but they keep the old codes though it seems useless for longer. The reason is that code can be used in future! In fact, 99% cases that useless code is not re-used in future but if they want to re-use they can get them from revision history.

The side affects if not practice YAGNI are:

• The project cost/time is increased while we spend time to add/maintain useless features, even we face the dead code problem.
• The size of project becomes bigger and complicated without any more aid-features to client.
• It can lead other features must do other way that takes more effort than normal. It is usually happen when TA/designer create the complex architecture that makes designer/developer have more works to adapt to ugly framework!
• Even when some feature is applied in future, it almost takes TA/designer/developer re-work/test to make sure it is run correctly or modify it much to adapt current system.

Practice YAGNI is a must during software development, reduce cost but increase quality always be a true thing. In almost cases, project manager and TA have the different views: project manager focus on scope and cost, TA focus on quality of architecture and they try to release a master piece of architecture to client. The good health project is the project can balance the needs of cost saving and quality of architecture. One good architecture can save the cost but bad one can make the cost increase significantly. As the one works in project, you should remember the YAGNI rule and follow it.

But how to avoid the YAGNI rule, it is not just implement what you need now but for future only. I means not predict what the future features can apply to project but make your architecture flexible enough to adapt the new requirements. One philosophy of design principles is "Design by enough but it is extensible for modification". Learning OO principles, design patterns also a strong analytics can help you have a good architecture, it is not need you try to guest what client needs in future.