On Thu, May 30, 2013 at 10:41 PM, Paul McNett <[email protected]> wrote:
> On 5/30/13 9:00 AM, Ken Kixmoeller (ProFox) wrote: > > I think to myself: "I > > *know* that they are going to need this, so I might as well..." > > Some things, it just makes sense to plan ahead. Like when the customer > says "we'll > never ever need more than one t-post in an opening, so just hard-code this > formula > for the one". When you just know that a couple years later they are going > to say > "what would it take to have the software compute 2 t-posts?" I re-write > their formula > to be more general and allow for an infinite number of t-posts. > It's true that, given sufficient variations in the data, all relationships are one-to-many. The problem is that, taken to it's logical conclusion, all data tables could have only one attribute. Take the classic name, address and telephone number record. We're pretty comfortable with the idea that folks have multiple phone numbers: business, personal, cellphone, vacation home, fax, etc. Just as they have multiple addresses. In some problem domains, people have multiple names: perhaps in different languages, or pseudonyms for authors. At the same time, it's nonsense to design a system where the number of related items is hard-coded: an order table with Item1, Item2, Item3 and Item4 because "we never fulfill an order for more than four items" is just doomed to failure. > And because they specifically asked for only one, I code the ui to only > allow one. > Then when a couple years do pass and they ask the question, I say "I'm so > good I can > have this for you in a jiffy" all because I was thinking ahead for them. > > But I'm constantly reeling myself in, realizing that I'm putting all kinds > of stuff > in prematurely that really don't have a business case. > > And that's the trick; balancing the needs of the one item with the needs of the many items. Sometimes your judgement leads one way; sometimes the other. Success depends on making a system just complex enough to be successful, just simple enough to develop. -- Ted "Starting Friday with a Trek reference" Roche Ted Roche & Associates, LLC http://www.tedroche.com --- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html --- _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/CACW6n4u26N5C96Cqdm2M7gS_K=zkwz2chmf8fopzadsxlj2...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
