How far do you go with YAGNI? [closed]

Question

I wholeheartedly agree with the YAGNI principle, but you still want to plan for success. If an application needs a complete rewrite when it suddenly has more than ten users, then it's YAGNI taken too far.

Some things You Are Gonna Need. From my perspective, the two most important points:

• Don't shoot yourself in the foot by not preparing your app for internationalization. If your application is any good, internationalization is going to be on the table one day. Also, the ability to handle foreign characters by using UTF-8 is an absolute requirement when building an application from scratch in 2010. Internationalization may seem not that important to an english native speaker, but believe me, it is essential and the pain of internationalizing an application later is horrible.

• Think twice about the no security features thing. What about an organization or group that wants to work with your app with users on different security levels. It could be that this is a feature you can really do without - I have a fine-grained security system built into many of my products that has never been used to its full potential yet. But think well about whether your specific application can do without, even if it is successful.

This is what they call "prototyping". Go for it.

There's a subtlety between YAGNI and prototyping.

1. When it's user-requested featuritis, and you say no, that's YAGNI.

2. When it's implementation (I18N, "decoupling"(?), queues, caches, timers, etc.) and you say no to yourself. That's not really YAGNI. That's prototyping.

Most of what you have here does not seem to be user-oriented gold-plating. I wouldn't call this -- precisely -- YAGNI.

YAGNI is about reminding you to see the difference between what you can do and what you need to do to satisfy your requirements.

For example,if your requirement says "let people create accounts and log in", just use your framework's default auth methods and move on to the next requirement.

Your web app can support OpenID, Active Directory, Local Database, Flat File, and a zillion other kinds of authentication methods, but you can satisfy the requirement by implementing the simplest one. (To me, YAGNI implies DTSTTCPW).

"I can do anything, given enough time"

- Every Programmer I've Ever Met

Not a fan of the YAGNI principle myself; I see it used far too often in the justification of poorly-designed software. Over-designed software is a problem too of course, but "YAGNI" doesn't really leave much room for actual impact analysis.

It turns out that in the world of software, many of the things that you think you aren't going to need, you actually are going to need. And then some. Who'dathunkit.

I've written one or two apps that were supposed to be throwaway apps or hold-overs that are still in production after two years. They are a pain to maintain.

Especially when it comes to something like security - you probably are going to need it.

YAGNI is a good principle but it is not the only design principle. Many of the above make sense to get a product in front of users quickly. But if, for example, the web pages that talk directly to the database begin to each have duplicated code you are going to find that slavish dependence on one principle (YAGNI) to the exclusion of others (in this case DRY) will limit your ability to respond to your hopefully growing number of users' feature requests.

If you are going to truly develop a revolutionary web application for the enterprise market I'm not really sure which of those things You Aint Gonna Need.

Also your examples are pretty specific. For instance when you say: "no security features"... I'd say that users is one thing you maybe can do without, but sanitizing your inputs is one you can't. Also "scalability" is not a matter of database sharding or replication, those are decisions you take after you realize your application does not scale well.

I'd rather be careful when using YAGNI as a high-level design guideline, It fit's best when you talk about odd product features or maybe software components extreme flexibility.

Just my 0.2

If you take "YAGNI" to that extreme (and I'll sidestep discussions on whether or not that's a good idea as well as discussions on whether or not that's really "YAGNI"), you should be prepared to mercilessly refactor your codebase to add in later what you leave out now without creating a Ball of Mud.