"Y.A.G.N.I — You aren't gonna need it"
S1 E3
What is "Better code saul" aboUt
The vision of "Better Code Saul" is to advocate good code practices and good coding design techniques in order to inspire others to adopt them and increment software's code quality.
The season one's mission of "Better Code Saul" is to provide a short-term benefit to your code quality.
The episodes succession is meant to be of incremental difficulty and each episode is useful for the following.
No, this acronym is not another Witcher sign.
In Extreme Programming (XP)
YAGNI stands for "You Aren't Gonna Need it"
What does this means for us developers?
Let's find out by example.
Y.A.G.N.I
Let's suppose you have to develop an e-commerce.
The e-commerce's business will be focusing on bike selling.
Your client needs to start ASAP in order to beat competition.
You estimate 2 months of work.
...But...
Your client starts telling you that he also loves cars and that his dream
is to dive also into the car selling business, one day, and to think about it while programming the e-commerce.
You have two options:
You stick to your original esteem, or you make a new one that also takes in account car selling management biz?
What are you going to do?
An example of "Y.A.G.N.I"
What are the pros of committing to the original estimate?
You keep your complexity to the minimal and you develop what you need.
You may need some refactoring later.
What are the pros of choosing the new estimate, implementing also the car selling part ?
You add more complexity upfront. You develop what you may need.
You won't need later refactoring.
What's the right choice?
Is there a right choice?
An example of "Y.A.G.N.I"
Let me tell you, straightforward, XP point of view.
According to XP and YAGNI principle, you should not build anything that is not necessary upfront.
Remember: Your client needs to start ASAP with bike selling.
You are responsible for your esteem of 2 months.
You don't want to lose time on other matters that are not urgent, or his business will suffer and so your professional relationship.
Who knows whether in 2 months your client will have changed his mind about car selling business?
If he changes his mind, or the market changes, you would have written useless code and added useless complexity to your software upfront.
Y.A.G.N.I — XP P.O.V
Never underestimate the upfront complexity added too early to your code.
It comes with a cost.
The code needs to be maintained and so its inherited complexity.
This complexity will add one week of work at a certain point in the future of your codebase, and that additional week will delay future features even further.
SOME CONSIDERATIONS
Of corse, wisdom comes with experience on the field.
Every project and every client have different needs.
YAGNI is a principle, but if you manage to understand it properly, there will be way more times in when you use it than the ones you don't.
You will understand the benefits that comes from minimal complexity each iteration on the project.
SOME CONSIDERATIONS
A personal advice.
We are developers. We love to think that our codebases are bulletproof to any edge case and we tend to think to every possible combination of features/events in order to create a very resilient application.
We seek perfection.
Well.. don't get fooled by this feeling. It's evil.
Remember, the best code with no errors and no flaws is no code at all.
But since this is not possible, because we wound't have any software then, a developer that really loves coding will keep his codebases as small as possible.
FINAL COMMENTS
RESOURCES
In no particular order, some resources I took inspiration for these slides and examples: