[ivraatiems]

I agree with that. I think the rule of thumb is:

The first time you do it, just get the job done as described. The second time, look for ways the two might be similar, but don't spend a lot of time on it. The third time, generalize and assume there will be a fourth, fifth, sixth, etc. time.

In the example the top poster gave, the first time it was requested, I would just write up some code for triggering the notification. The second time, maybe there's a shared class (or whatever) for notifications with text passed in. The third time, now maybe we need the ability to specify notification text in config or DB or through user-triggered actions.

[giantg2]

Ideally, the business should have their processes defined before ever implementing them technically. So these architectural questions should mostly be addressable from the start. Knowing hoe the processes look upfront can actually lead to some wonderful designs rather than constant reactors. We had a system that we knew from the start would have multiple UI layouts for multiple workflows that shared mostly similar data. We were able to build the UI to dynamically build the pages based on the data.