Let it goooo, let it goooooooo!
Introduction
Yes, yes, I know. Yet another acronym. But I promise, it is almost over. YAGNI is one of the extreme programming paradigms that is used for agile software development. Even though you might not consider yourself an extreme programmer you should definitely pay a lot attention to YAGNI. It stands for You Ain’t Gonna Need It, and will help you stop wasting time.
The Problem with this problem
Developers tend to overcomplicate or overthink their tasks. I guess everyone knows these sentences:
- The customer will definitely love it if I integrate this cool feature.
- What if next week I have to implement this for the User class?
- If I implement this now, it will safe time later.
So we write more code than we are expected to complete our given task only on presumptions that features X might be useful or method Y might change in the future. So mostly two things will happen:
- We spend time writing code that will not be used in the final release.
- We spend time writing code that will be used, but on false assuptions. So we have to rewrite it later.
This is wasted time. Period.
Recatorying baby
So how do we solve this problem. Easy: stop doing it!
The best way to solve the problem is to first find out what exactly is needed. What are the minimum required classes, methods, variables to code the task. In order to find this out you have to break the problem into smaller pieces. Then break down each piece again. And again. And again. After doing so you get a better idea of what you really need to get the very first running version. This will lead to leaner and cleaner code. Now build exactly this version without any fancy features. This version should compile and run bug free. Congratulations, you just used the YAGNI principle. But it ain’t over yet. Now the fun part begins. Start a refactoring session. This will lead to good quality code which is easier to maintain and extend. So if in the future a new feature will be in demand, your code is very well prepared to easily adapt and evolve.
What have we learned?
The best way to deal with your wishes to develop every single super cool feature is to not build it. Instead
- Think and break down first
- Write code second
- Refactor last
This way, you will spare yourself a lot of wasted time.