Aren't we misusing YAGNI too often?

Arseni Mourzenko
Founder and lead developer
December 20, 2014
Tags: refactoring 11 rant 33 short 48

OK, I get it, I'm over-think­ing and over-en­gi­neer­ing this app. I should KISS, be­cause YAG­NI. Great. I should not at­tempt to solve prob­lems I don't have.

I should not at­tempt to solve prob­lems I don't have.

Or should I?

De­vel­op­ment is filled with com­pro­mis­es and gold­en mid­dle.

In a con­text of con­tin­u­ous refac­tor­ing, there is a ten­den­cy to ap­ply YAG­NI as strict­ly as pos­si­ble, which makes sense in the­o­ry. In the­o­ry, this leads to per­ma­nent sim­plic­i­ty, which means that at in­stant t, the code is as sim­ple as pos­si­ble be­cause (1) it was refac­tored from a more com­pli­cat­ed form and (2) no un­need­ed com­plex­i­ty is pre­sent in the first place.

In prac­tice, I see a bit too of­ten how YAG­NI hurts me and teams I'm work­ing with. A good ex­am­ple: my ques­tion What are the valid uses of sta­t­ic class­es? on Pro­gram­mers.SE. The first an­swer, ob­vi­ous­ly: YAG­NI: sta­t­ic class­es are sim­pler than de­pen­den­cy in­jec­tion or oth­er con­structs.

I un­der­stand the point, but I still dis­agree. 259 char­ac­ters lim­it for file paths in .NET Frame­work was hurt­ing me in dozens of pro­jects, and al­ways when I was not pre­pared to be hurt. For ex­am­ple, I re­lease the sys­tem used in­ter­nal­ly in my com­pa­ny for the repli­ca­tion of files. It works for a while, and then starts to fail be­cause there are now files which ex­ceed the 259 char­ac­ters lim­it. So now I need to deal with this, and do it quick­ly, but since I've used the sta­t­ic File class, I should now change a great deal of the code and the tests to make it work cor­rect­ly. TAG­NI now costs me six hours of work I could eas­i­ly avoid.

The worst part is that it some­times doesn't cost too much to “over-en­gi­neer” in the first place. Us­ing the li­brary which let you ac­cess ei­ther the file sys­tem or iso­lat­ed stor­age, or mem­o­ry, or specif­i­cal­ly NTFS with its trans­ac­tion­al ca­pa­bil­i­ties and sup­port for long names isn't that more dif­fi­cult com­pared to the calls to the sta­t­ic File class.

Ac­tu­al­ly, I be­lieve YAG­NI might be the rea­son we have the 259-char­ac­ters lim­i­ta­tion in the first place (note that I'm un­aware of the ac­tu­al rea­sons, so this para­graph is pure­ly spec­u­la­tive). Long ago, they de­signed a sys­tem which sup­ports the ar­bi­trary lim­it which seemed rea­son­able. Since it was in­deed rea­son­able and be­cause of YAG­NI, they de­vel­oped the sys­tem in a way the length can­not be changed. Years lat­er, the lim­i­ta­tion be­comes a real is­sue, but chang­ing the lim­it is now too ex­pen­sive to be pos­si­ble in prac­tice.

Who needs to store 2 TB of data in a sin­gle file? Thir­ty years ago, no­body. To­day, a lot of com­pa­nies. In a few years or decades, prob­a­bly any av­er­age user.

Who needs 100 Mbps in­ter­net con­nec­tion? Thir­ty years ago, no­body. To­day, a lots of per­sons. Very soon, prob­a­bly any user of Net­flix or YouTube.

Let's talk about data­bas­es. When de­sign­ing a data­base schema, there is of­ten a ques­tion of type for an unique iden­ti­fi­er. int ap­pears a good choice for most ta­bles. But then, your pro­ject is a huge suc­cess, and you've got your 2,147,483,647th com­ment, and the next per­son who com­ments makes your web­site crash. Why this makes me think about Y2K prob­lem?

YAG­NI is an ex­cel­lent prin­ci­ple. But like any oth­er prin­ci­ple in soft­ware de­vel­op­ment, it may eas­i­ly be mis­used. Us­ing every time the eas­i­est de­sign with­out both­er­ing about to­mor­row is cer­tain­ly not the best prac­tice, even in a con­text of reg­u­lar refac­tor­ing.