In the development of most any project, there comes a time when there appears the potential for a really awesome feature or just a really neat abstraction.

At these crossroads, a junior software developer is likely to be turned towards “You Aint’ Gonna Need It” (YAGNI) by a more senior software developer. A senior software developer will either tell themself YAGNI, or they will go ahead and make the call “maybe I will need it”. This is where the danger starts.

Engineering

A common set of phrases I hear to justify “maybe I will need it” tend to use the word “engineered”. My theory is that this lends credibility. “Engineered a solution” sounds a lot better than “I have a gut feeling”, “experience tells me this”, or worse, “my resume needs this”.

Now I’m being unfair, there are many legitimate reasons to justify “maybe I will need this”. Many cases do exist where it may actually be an engineered design.

What I’m trying to claim, is that many software development projects don’t exist with a formal design specification.

What I’ve generally been a part of is a goal, a deadline, a chosen programming language, and maybe a base framework to build on (or a pre-existing application). The requirement is to reach the goal as closely as possible by the deadline. This kind of software development necessitates a lot of judgment calls by the software developers.

YAGNI is the rule of thumb for software development with a deadline. Deadlines are already tight and anything not strictly necessary will be cut from the product.

YAGNI is “reactive engineering”: building what we need, only as we need it. Zero waste because we don’t build anything we don’t need.

Proactive Engineering

I just made the claim “zero waste” and that sounds really nice, now let me call it “potentially inefficient”.

Part of deadline-driven-development with YAGNI is that refactoring and reworking old code isn’t often a part of the deadline. It’s not producing any “value” for the deadline’s goal, and so clean-up is just ignored.

Worse, perhaps a component or feature was poorly built previously, in a way that is not reusable or composable. Two choices are presented to the software developer:

• The first choice is to build a new abstraction, refactor the old code, and make it one component that is used everywhere, which can then also efficiently be used in the future.
• The second choice is to spend less time and build a new component that does the same thing but now duplicates functionality, and isn’t reusable either.

That second choice is the more popular one because it’s less uncertain, less time, and it doesn’t involve changing old code which might break.

If YAGNI is “reactive engineering”, there’s also the flip side of “maybe I will need it” and “proactive engineering”. A scale might exist on the software engineering scale of “reactive” to “proactive”.

“Proactive engineering” might not be zero waste development. If time is spent on something and it turns out to not be a helpful feature or abstraction, that time is “wasted”.

The Business

“The Business” is a term thrown around to designate everyone but software developers. I’d rather like to look at this term a different way as the entirety of the business including the software developers and to be used by a software developer to examine both himself and “the business” as a whole.

“The business” is barging into this topic because I believe that proactive engineering and applying “maybe I will need it” is only effective when the software developer understands the business needs, both as a company and as a software product.

Summary

Knowing when You Ain’t Gonna Need It comes with experience. Know where you are on the scale of reactive to proactive engineering and what your business needs.