YAGNI – Abused, Molested and Misunderstood

Posted: April 1, 2013 in Clean Code, Development General
Tags: , , ,

Nowadays is really difficult to be reading anything about software development without stumbling upon a web page, blog, book, article or the like that discusses software development / design principles. SOLID, KISS, and YAGNI are acronyms that come up in lots of discussions among developers which is good, it means that most people are aware about the importance of good practices in order to build robust applications that do not end up in a maintenance nightmare. The only problem is that I have seen people use them in such a way that they end up being the justification for poor, tightly coupled, difficult to maintain software.

But, I hear you say, how can principles that are supposed to enforce good software be used to produce the opposite? I believe is part of human nature. We can find in history too many examples of things that were created for good that end up being used for evil. In the case of these design principles I believe that a lot of developers really do not want to change the way they have always develop software because, let’s face it, once you are comfortable doing something it is really painful to do the exact same think in a completely different way, so it seems that it is much easier to try to convince others, and ourselves, that our way of doing things is the way that comply with said principles.

Unfortunately most of the time this way is not the way things should be done because it is, well, the way things have always been done that have ended in tightly coupled, spaghetti code. In particular I have been involved in some discussions in which people argued that the idea that good development techniques to decouple software like IoC or dependency injection should not be used, at least not at the beginning, under the YAGNI flag. The “You Ain’t Gonna Need It” idea does have a lot of promise of not adding unnecessary complexity to a piece of software if at that moment there are no requirements that justify it. This is always helpful when you hear someone saying something like “but what if they need to add more types of foo?” That is a valid question to which the answer can always be “what if that requirement is never defined?” The problem comes when you hear people saying that decoupling infrastructure should only be implemented as the need arises because it is not needed from the beginning and it will only add complexity to the code.

By following this last recommendation, the question that comes to mind is when will this decoupling optimization be needed? When the code is so tangled up that it would take weeks to refactor it and break all the dependencies? Is it when each time we are trying to add a feature or fix a defect we end up breaking the application in lots of different places? Maybe when you start hearing developers say they do not want to touch or change a particular section of the code? If all of these scenarios are not something we would like to have in our code then how can employing proved techniques, like IoC or dependency injection, that really do not add that much to the complexity of the code be harmful?

Now days we can even unit test all kinds of tightly coupled messes thanks to tools like TypeMock and MS Fakes. The problem is that these tools are making some people believe that IoC and dependency injection are no longer needed because those techniques’ only purpose was to achieve testability and now we can mock hard coded dependencies. But even with this kind of code all covered with tests, refactoring, fixing defects, and adding features can be a titanic endeavor just because we did not take the time to properly design the application from the beginning because of YAGNI.

As professional, software developers, coders, software engineers, or whatever you want to call us, we need to understand that if someone is going to need more than a couple of hours to at least figure out how the code we wrote works, and that includes both the production code and the tests, then it is not quality code. Having loosely coupled, isolated code aids in this understanding and we need to defend the practices and ideas that have come to improve the way we develop software and not use them to go back and do the ones that we have already left behind.

Advertisements
Comments
  1. sergeromero says:

    I totally agree, unfortunately there still are a lot of people who skip the refactoring step or do so in a light fashion.

  2. “[…] the question that comes to mind is when will this decoupling optimization be needed?”

    One way to answer this question: http://c2.com/cgi/wiki?OneTwoThreeRefactor

Does this make sense to you?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s