Is YAGNI overrated?

What is this principle and how can it be a guiding factor when designing your codes?

What is YAGNI?

You Aint Gonna Need It (YAGNI) is a principle of extreme programming (XP) that states a programmer should not add functionality until deemed necessary. Wikipedia

Why YAGNI is relevant in Software Development Lifecycle?

When we start implementing features, we often find ourselves getting into a practice commonly known as feature creep. We try to add or improve features even if the user has not requested for them yet. For instance, we might try adding validation to a form without first completing the CRUD in the database.

Therefore by following this principle early on in the development lifecycle, we are able to implement features that will only be relevant to the first iterations or demo.

Still at this stage, we have the tendency to micro optimise our codes instead of building iterations for getting feedback quickly from the product owner or project manager.

Yagni vs Micro Optimising

Do Things that Don't Scale - Paul Graham

The other end of the spectrum is Micro Optimising, which is, to try to optimise a piece of code or functionality to it's best. The problem with this approach is we can lose a lot of time deciding on the best course of action such as trying to use for loops in JavaScript versus a simple Array map function just to gain a few microseconds.

The idea is to make it work first, then improve it; not the other way round. For example, you can code multiple behaviours in a single function first - just to make it work - and once done, you then separate it into different functions respectively.

So when can YAGNI be bad advice then?

This principle is relevant when building Minimum Viable Products (MVP), Proof of Concept (POC) or when doing quick demos to a customer. But often times, for Enterprise Applications, it makes a system more difficult to change.

Let me illustrate this scenario with something that recently cropped up at work.

Payment Feature

In a Management Information System (MIS) project, a colleague has hardcoded url for a payment solution. Now if you want to change from test to production environment, you need to go into the codes and change it along with the other credentials.

For him, implementing the system at the time - particularly for testing and having a quick demo - was enough. Within this context, he did not need to refactor the codes for the addition of Environment Variations (ENV) and Database values.

Now that the colleague is no longer working at the same company, someone else needs to update the urls from test to production. First, the new colleague who is going to work on it:

• needs to learn the basic payment documentation
• understand the flow, which is complicated for such features (get authorisation, initiate payment and open in third party window)
• after changing the codes, he or she needs to test it for regression and other things that might stop working
• the latter has to also run tests and make sure the builds are complete

A lot of work for simply changing an URL.

Simple vs Complicated

That's what is a complicated system or sub system. You need a lot of steps to perform a change. A simpler system is designed for change - even though - it's initially more challenging and time consuming to implement it.

In the payment scenario above, you can code a model to get the URLS from a database depending on the current client (multi-tenancy), and loads it directly in the application.

The person only needs to login in the database and change the urls and credentials and he or she is good to go.

Therefore, even if following the YAGNI principle is highly recommended at the beginning of a project, a better advise is to design a system that is easier to change particularly for Enterprise Apps.