Coding Practice: YAGNI

Coding   Practice: What is the minimum code needed to do a task?
There is this concept of calling YAGNI (You Aren’t Gonna Need It) on a chunk of code that you have written to do something above and beyond what is needed to meet the needs of a PBI. As a rule of thumb, you want to do the simplest thing that could possibly work.This doesn’t mean that you don’t want to take the effort to make your code testable or to improve the coupling and cohesion so your code accepts change well.  It just means that you don’t want to guess at what the future holds and waste time in over analysis or on writing code that will never be used.

“… we’re talking about saving 1-2 man   hours of effort tops [per scenario], but this type of scenario happens hundreds of times on a sizable project…  The power of YAGNI and “The Simplest Thing” is that it enables you to reduce the risk that the project totally fails by allowing the dev team to focus on the most important aspects of the system before tackling ‘nice to do’ items.”
–            Jeremy Miller

A classic example of YAGNI is the habit of extracting out functions into a utility class.  Having done this myself before, I know the thought process is something like “this function might get used in multiple places someday, so I better put it somewhere centralized to promote reuse”.  The problem is that if we don’t have a need for that code in multiple places at that point in time, then we are guessing at the future.  In this case, a couple bad things happen when we guess wrong:

1) Sometimes our   utility method only ever gets used once.  So we don’t get any reuse benefit, and our code becomes less readable since the utility method call is out of context, when really it should just be a method in our class, since that is the only place it ever gets used.

2) Sometimes someone changes our code to no longer need the utility method, but since the method is in a global utility class, we assume that it must be getting used somewhere.  So the code hangs around forever in a utility class never getting used.

Note: In general, we should avoid global utility classes altogether since they aren’t really in the spirit of OOD; however since this example is true for multiple projects and it represents YAGNI, I thought I would go with it.

The moral of the story is to just be careful to not build stuff you aren’t going to need just because you “might” need it someday.  Just remember, YAGNI.


About Chris VanHoose

Principal Software Architect at CT Lien Solutions
This entry was posted in Software Architecture and tagged , . Bookmark the permalink.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

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

Facebook photo

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

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.