YAGNI Doesn’t Always Apply
YAGNI means You Aren’t Going to Need It. It’s a software development philosophy that suggests features should not be added until a customer (or product owner) asks for them. Many times, you really aren’t going to need it, but if you apply YAGNI incorrectly you may get yourself into a bit of trouble and your code may begin to smell.
Occasionally I witness YAGNI being applied to the last step of the Red-Green-Refactor process prescribed by TDD. Skipping the crucial refactoring step results in code quality that progressively worsens over time, which leads to reduce velocity, increased bugs, and eventually a rewrite. You should always leave the code better than you found it and make it as easy as possible for the next programmer to understand and change. Refactoring just-in-time when you need to add another feature is often suggested as a better alternative, but doesn’t always work well. If it’s another programmer doing the work they need to understand your poorly factored code first which isn’t only frustrating, it probably also has a serious impact on their velocity. It’s easy to justify skipping that refactoring step by suggesting nobody can prove that you need to do it. After all, your feature is working now. However, that is akin to saying nobody can prove that you need the code you’re writing to be maintainable.
We all want to write maintainable, beautiful code, which should mean that we understand the importance of applying the refactoring step as habitually as our morning hygiene routine. It should also be obvious that YAGNI doesn’t apply to refactoring if one of your goals is to create a codebase that’s easy to understand and cost effective to maintain. Knowing exactly how and when to refactor is another question for a future post.
0 Comments