Ed Leafe wrote: > I've worked for many clients who made claims like "we will never need > more than one phone number per customer" or "part numbers will never be more > than 4 places" or "640K will be enough for anyone". (OK, that last one wasn't > from one of my clients!).
It's become a running joke between myself and my principle contact at my main client. They keep constraining what I do based on what they think will get the job done faster (more cheaply). So they say, for example: "There will never ever be the need for more than one t-post" which means I don't need to set up a 1:many relationship or really do any normalization at all. I get the job done pretty quickly and it works well. We maintain it and enhance it over the years as needs change and business rules flex with the times. This was 1998. Flash forward to 2006 and customers are now wanting 2-4 t-posts plus horizontal t-posts (which were another "we'll never need this" option back then). Now we need to either graft the new requirements onto the existing framework, or redesign the whole module from scratch, including converting the old data to the new model, testing, and deploying in the most non-distruptive way possible. IOW, allowing for the 1:many design from the outset, even though the need wasn't foreseen, and even though the need for an infinite number of t-posts would never materialize, would have been the best decision for them, because making such a fundamental change later on takes way more time and energy than designing it in at the outset. There are many such examples in my client relationships. For this one client, I make a point of finding the original email where she says "we'll never need this" and replying to it with a wink. But she still never learns. ;) Paul _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/[email protected]
