I believe your case proves the exception of the rule. When talking about Frameworks and coding tools you have to build constantly thinking ahead of time. A framework feature that is not used can easily be ignored in the end product, so you may have a set of classes and you are using just a few of them. Besides you would never know if some of your code is ever used, you have to build the tools by playing all possibilities out in your mind. This is a very interesting task.

The yagni principle could not apply here. In my experience yagni is less of a programmer's issues but more a manager's issue.

But it is also a hardware issue. We had a client that demanded a server specs to maintain 10 years of production data. It turns out in the end they paid over 5 times the necessary amount because five years later they could update the server hardware at a fraction of the initial cost and got even much more than the original 10 years estimated production size.


>YAGNI is a tough one IMHO. It depends on what you're building. When I start new applications I tend to spend a lot of time putting all the core pieces I **am likely to need** into place. This is usually a fairly involved effort and there are pieces that will end up not getting used. But it's easier to put them in the beginning in case they are needed than add them later.
>
>On a LOL note: Also as a framework and tools builder it's my job to anticipate what features people want and are likely to need so I'm often doing the opposite of YAGNI :-)
>
>A lot of that comes with experience - if you've been doing development for a while you're likely to have a pretty good feel what's worth implementing up front and what's better left until needed.
>
>+++ Rick ---
>
>
>>>Don't Repeat Yourself
>>- as in don't repeat code (unless it is trivial)...have not done that for decades :-)
>>
>>>You Ain't Gonna Need It
>>- this one I don't get - explain?