Yes, it is more art than science - we have probably all worked for a client (or boss) where you ask about a particular feature and in your mind you can see that the problem at hand is just a pattern of a more generic problem.

So you try to flesh it out with them "would you ever use this for such-and-such" and even after the same question in various ways (to quote a playright, "careful questioning will flush them out"), they still say no. And so you build it as requested because it is faster to do it in a specific way for the problem at hand. And then x years later they say that they like it so much could you now incorporate it doing such and such. And so you then either duplicate the processes in new code or refactor the code (and perhaps tables) to handle the new problem.

Or you do like I did for this one client where they wanted a "callback" setup where for every file open for a client (lawyer), when they last work on the file, they set a "call back" date (3 mos, 6 mos. etc) that if the client has not done anything on the file, they make a call to the lawyer. To me, this just looked like a task list with a future "due date" and so I decided to set it in a more generic sense - table fields are generic ("Task_ID" for primary key instead of "CallBack_ID" etc) and then an extra field in the table for sub-table support for "Task Type" (which = "callback"). Then the dialogs and prompts where made generic by passing in the callback type etc. After 14 years of using it (I just checked it), they have not asked for another type of "task". It was a binary crap shoot - I would have looked like the hero if they had requested it be used for something else but so far, no dice. As it was, I gave them the estimate of time based upon doing it generically and they did not have a problem with it.

I would say that overall though after a few of these hits and misses, I still tend to try to think of the future possible uses and design in a way that allows for some future use as that seems to be the more frequent request from customers - and I hate having to refactor a class when it is done too specifically.

Albert

>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?