YAGNI

I recently read a blog post regarding the YAGNI principle of programming.The acronym stands for “You Aren’t Gonna Need It!”.The idea really hit home for me because, while I’ve never heard it before, I have seen its truthfulness play out time and again in my programming career.In hindsight, this approach could have saved me countless hours of coding/testing/debugging/refactoring on features that were not ever used.Putting that time and effort to good use on the parts of my projects that were actually used could have benefited not only me, but my managers and employers.

One example was a project I worked on in the early days of .NET 1.0.We were porting an ASP web app with a C++ back end to use C# and ASP.NET.The lead developer/architect insisted on building an overly complicated process to protect the code from any unexpected changes to the underlying data structures.In theory, it was a useful feature, employing a command-line app to generate strongly-typed datasets, which allowed us to be notified at compile-time of any changes to the structure and modify our code accordingly.What was missing from that equation, however, was the fact that during the 3-year duration of the project, the number of data structure changes could be counted on one hand.And each of those changes was thoroughly documented well ahead of time, so the requisite changes on our end could be made at the appropriate time.

In addition to the added time spent building and maintaining the supporting app, this approach forced developers to retrieve data in a rigid and non-performant fashion.The resulting complexity slowed down development of core pieces of the application and ultimately led to more bugs and less readable and less maintainable code.The debate raged within the development team about whether or not this was the appropriate way to architect the application, but its clear in looking back that the most efficient use of our time and resources would have been to avoid the added complexity and build only what we needed, only when we needed it.

More recently, a development manager that I worked for was fond of designing elaborate and complex solutions to problems that we had not yet encountered.Often, this involved some new design pattern he had read about and wanted to find a way to work into our project.The result was seemingly constant revisions to the product release dates, as well as sometimes tense discussions with upper management trying to rationalize the delays.Also, we frequently had to deal with performance issues due to unnecessary layers in the architecture.We finally made the decision to pare down the code base to just the basics, and the resulting simplicity and improved performance was refreshing!

Having lived and learned, I vow never to build in features before I need them.My time is too valuable to spend on something that may never be used, no matter how brilliant it may seem at the time!