Today I was reading a good example of how software can get out of control. In an effort to future proof software designs or assure that it can never be used in a manner for which it was intended simple software is wrapped with development patterns that fit, work, and even make the software bullet proof. However, the original intention for which the software was meant to perform is lost in all the layers of abstraction and forced implementation.
I thought YAGNI was a name for someone when I first heard the term, later to be corrected with the true meaning, “You Aren’t Going to Need It”. How often do we spend a lot of time future proofing something and years later find you didn’t need it.
For this reason tools such as unit tests or contracts continue to grow in popularity. The biggest fear of not fully implementing all the possible edge cases of some library is that enhancing it in the future may cause regression issues, breaking the original intent. Unit tests and contracts may be used in the initial design confirming the correctness off software. Then as the software is modified over time, the tests and contracts continue to validate the original intentions and may be extended for new behaviors.
YAGNI and automated testing go hand in hand allowing you to not future proof your software and at the same time modify your software in the future with confidence that you have not broken something important.
So, write software that others can understand. Keep it simple until you have requirements to make it more complicated using design patterns.
Check out this example of YAGNI at http://chaosinmotion.com/blog/?p=622 which prompted me to write on the topic.
Cheers,
Ben