Hey there, brothers… Brothers in arms
Wassup… What’s going on?

In this write-up, I talk about YAGNI.
I’ll talk about how important it is when writing software. I’ll share my industry experiences with it.

So, without any further ado…
Let’s get on with it

 

1. What is YAGNI?

YAGNI is as an acronym for You Aren’t Gonna Need It. It’s a principle which comes straight out of Extreme programming.

Well, I prefer to call it one of the software development best practices.

Ok, I get it. But I am still not sure. How helpful, is this principle in writing software?

Simply put, YAGNI means don’t create something until & unless you really need it. There is a high probability that You aren’t gonna need it. Why waste time & resources?

While writing software, there are so many instances where some features or flows or functionalities aren’t required or don’t matter much. But we are so inclined towards perfecting stuff that we end up exhausting a crapload of our resources on it. Further delaying the completion date of our product.

What do we really get? A sense of closure 🙂 Maybe. You tell me.

If you’ve been writing software for a while, you know what I am talking about. I’ll further share my experiences where I strongly felt that time could have been saved working on other high priority stuff.

 

2. Real-World Industry Examples Where YAGNI Could Have Really Saved The Day


2.1 Building MVP Minimum Viable Product

This is a pretty common thing which I’ve seen with myself, my geek friends & in the developer community as a whole.

We are always so excited when writing something new. Be it anything. Creating a product from scratch, a software service or anything.

Being freakin amped about including a gamut of features in our product, we just don’t want to cut out anything at all. The initial version of the software should contain everything we have ever thought in context to our project.

Well, I’ve always found this, brimming with excitement & happiness, feeling do more harm than good to launch a product within a deadline.

This is where YAGNI kicks in. There is a really high possibility we might not need all the features for the launch of our MVP.

Just an initial set of features is required for the MVP to be launched in the market to test out the waters. Also, to gain customer feedback. If any features they require specifically in the product or so.

Based on these responses, teams plan out, prioritize future feature rollouts. Also, the features unnecessarily pre-developed might deem out completely useless based on the public response of the product.

We just cannot know everything before taking the product out in the market.

So, it’s always advisable to stick to important stuff & weed out things which we might not even need.

There is one more factor. As soon we start building anything new, the motivational clock starts ticking. We have to get to the finish line within the stipulated time else lack of motivation throws a wrench in the gears big time. The technical debt keeps piling up.

 

2.2 Over-Optimizing Code When Not Really Required

2.2.1 Fixing an Extra DB Call

So, once I with a couple of devs were building a module responsible for optimizing the product images on the backend enabling faster page loads.

The feature looked good, worked pretty fast. There was just one hitch, a particular flow made just one extra database call. Just one call extra.

Honestly, if you ask me. I would let it slide for the initial release & list that thing out for future iterations.

Well, One: the feature worked asynchronously so it wasn’t hindering any user triggered flow. Two: the whole thing worked pretty fast & just didn’t require investing time to juice out every bit of performance.

We may had to re-design the flow after all & the release would have been delayed.

But we were crazy enough to delay the release for 5 days & fix that thing. Boy… The change was good but no significant change in performance.

We could have deployed the code & fixed the DB call, if required, in future.

This is one instance where we should have thought better. YAGNI again. You ain’t gonna need it bruh!!

 

2.2.2 Using a Map in place of a List

Another instance of YAGNI. In our production code, we had a list of product types. And to find a particular product type the flow would loop through the list & find the product.

Now, on going through the code, anyone would point out and exclaim. Hey, why don’t you use a map? if you are looking for a string every time.

Won’t that be O(1) rather than O(n) where n is the number of product types?  

Yeah, I agree. But brother, the code with the list is already there. It’s running in production. Is a refactoring worth it?

Also, the product types are really limited. There is no way they are growing to tens of thousands or even hundreds. Software changes have costs associated with it. We had a pretty solid debate on this.

Well, the code still should be changed or not, is subjective & debatable. I would note this for future optimization in my to do list & let it slide for now.

What would you do? I would love to know your views on this.

 

2.3 Being Attracted to Shiny New Tools in the Market, without the proper Use Case Knowledge

Just like children we are always so attracted towards shiny new stuff in the market. Frameworks, tools, libraries. New technologies. Be it anything.

You can obviously relate to what I am talking about. Nobody wants to work on the old stuff. Meh!!

When building something we always and always prefer to implement the new stuff. We would always want our database to be a state-of-the-art NoSQL tech than the conventional SQL solution.

But, do we really need it? How sure are we that we just cannot do without the new stuff to solve our problems?

A very quintessential example of this is, in the industry, switching to NoSQL solutions from the traditional SQL ones, just because it’s new. Must be more advanced. Or it’s the industry trend.

This is a recipe for a disaster. YAGNI again. You aren’t gonna need it bruh.

Until & unless your production systems are on fire, failing you, letting you down. It’s pointless transitioning to new stuff. Every transition has immense costs associated with it. Every new tech has its own quirks & limitations.

We cannot fathom how much an unnecessary transition can blow up on our business.

Use your experience & wisdom. Take it step by step. Try to keep things simple. Always.

 

More on the Blog

The Ultimate Guide to Federated Architecture & Decentralized Social Networks

What Does Software Metric Mean In Software Engineering & Live Production Systems?

Google Cloud Firebase – What, Why, How, Use Cases – Everything About It

How to Pick the Right Backend Language For Your App – Explained With Use Cases

How Does PayPal Processes Billions of Messages Per Day with Reactive Streams?

 

Ohk!! Alright… Phew. Enough of wisdom.

So, these are just some of so many instances out there. Where YAGNI can be applied & ideally should be applied.

Keep things simple. Take a breather. Enjoy writing code, build super awesome stuff. Launch it & give me a teeny tiny equity of it. That’s all I ask.

If you liked the article. Share your views in the comments. Share it with your geek friends.

See you in the next article.
Until then
Cheers…