Read on Twitter
YAGNI - You Ain't Gonna Need It
YAGNI is a key principle of extreme programming.
But what is it about, and do you really need it?
YAGNI is a key principle of extreme programming.
But what is it about, and do you really need it?
What does it say?The statement YAGNI sets is pretty simple:
Only implement things when you really need them, not when you think or foresee that you might need them in the future!
You could view YAGNI as an advocate for just-in-time manufacturing. Manufacturing being writing code and delivering features in this case.
Only if someone really requests a feature to exist, you get to work and create it.
Otherwise, you stay the lazy being you are!
Only if someone really requests a feature to exist, you get to work and create it.
Otherwise, you stay the lazy being you are!
Why is it important?Every line of code not written is time and thus money saved.
But it is even more!
It is:
- Less code to maintain
- Less code to test
- Less code to refactor when things change
- More time for more important features
- More time for documentation
And it also is:
- Time saved on compilation / transpilation
- Time saved on tests run
- Resources saved at build time / runtime
- Knowledge you don't have to keep somehow
- Time saved on compilation / transpilation
- Time saved on tests run
- Resources saved at build time / runtime
- Knowledge you don't have to keep somehow
What does it prevent?Most software development nowadays is performed on client's request.
Whether you work in a product company, in a company offering development services or somewhere else.
There is someone, somewhere, that would like to have a certain feature.
It's either your client requesting a feature with a certain set of requirements, or a product manager reacting to customer feedback.
Whoever or whatever the actual driver is, this is the point where the actual requirements come in, neither sooner nor later.
Whoever or whatever the actual driver is, this is the point where the actual requirements come in, neither sooner nor later.
The chances of you foreseeing the requirements of a future feature request correctly are pretty low.
So there is a high chance of you implementing _something_ which is not the _something_ your actual stakeholder wants.
It's like playing the lottery!
So there is a high chance of you implementing _something_ which is not the _something_ your actual stakeholder wants.
It's like playing the lottery!
Implementing something prematurely will most likely result in everything being thrown away again.
This is a scenario no one really likes!
And then there's another scenario which is sometimes more likely to happen:
No one really needs that feature!
This is a scenario no one really likes!
And then there's another scenario which is sometimes more likely to happen:
No one really needs that feature!
