If you came here thinking the famous Greek pianist had become a trailblazer I am sorry to dissapoint you but that's Yanni.  Yagni, is an extreme programming principle that can be applied to Salesforce or the development of any system and it stands for You aren't gonna need it.  

This term has been resonating in my mind a lot recently as the current project I am working on requires an integration with an existing data model which has a large number of fields which are actually not used or that don't belong to the business process for the system component in question, and I have been putting a lot of effort in  ensuring we don't inherit this on the Salesforce side of the integration. The reason these fields exist is that it was thought to be a good idea to have them to get ready for when we actually need them, you can see where this is going...

YAGNI argues that you should not build components or features just because you think you may need them in the future. This should not be misinterpreted as do not build an extensible system because you don't currently see any additional use cases for the system, this means, focus on what is important now and do not use resources (technical or human) on things that do not add value at the moment or even more important, things that would consume the time and resources that could be spent on the features that would add value right now.

I am a big fan of extreme programming methods and I feel that in an ecosystem like Salesforce in which developer resources can be expensive, components are limited, that is, a maximum number of fields per object, sharing rules, API calls, you name it.... but that at the same time is an environment in which in the mind of the project team, is so easy to add components, this then becomes an extremely important mantra to have present throughout the design and build phases of any project to avoid over-engineered, messy systems.


Building unnecessary features now will not necessarily mean we will save the time and cost when these features are needed,  because by the time they become requirements they are likely to be different to what we have envisioned or the downstream system that would use them would require them in a different format or your current system will have changed anyway, so what you may see as an opportunity to save on the cost of future build time will become the cost
of refactoring
in the future.