Issues where we may need to add complexity to handle relatively rare events. Tips on how to deal with those.

-------

''Big-Ass Text-Note Solution''

Under the CampusExample, 2 addresses per student was deemed plenty sufficient for most students. However, what about those who need 3 or more? I suggested having a large "comment" field to put any special or custom stuff rather than make a formal multi-address CrudScreen set.

----  
Why is two special? The system supports either 0, 1, or more than 1.  After you've decided to support 2, supporting any multiple is really a trivial amount of extra work.  In fact, having two and no more than two is a special case, and it would end up being more complex in many ways. cf TwoIsAnImpossibleNumber, ZeroOneInfinity, ZeroOneInfinityRule.

''Two is special in this case because of standardization and the definition of the information in an address; how many fifty-line addresses are there?  If you were working on a bicycle object, would you define an arbitrary number of wheels, particularly as a first design? -- BrentNewhall''

No... a bicyle was one drive wheel and one steering wheel.  If we're going to have two steering, the same abstraction that allows for two will allow for 10 if necessary.  ''Or two or more drive wheels. Tricyle anyone?''

A better example might be the drive mechanism of a bicycle.  Either you have one chainwheel sprocket and one freewheel sprocket, or you have a mechanism to change gears, in which case having 2 and 5 or 3 and 7 makes no difference.  -- AnonymousDonor

I generally disagree that if you make 2 then you can make a jillion. Look at the user interface, for example. If you have 2 addresses, then you have a screen with 2 address panels/areas. Lets call them "short-term address" and "long-term address". The user can fill both of them in or leave one blank. However, if we have the number open-ended, then we need to have Add Address, Edit Address, Delete Address, List Address, etc. use cases and buttons, etc. The user interface is now more complex with more options and more ways to confuse the user and more things to go wrong. It may even make more user key/mouse-strokes for the vast majority of student records that have no more than two.

I see no reason to make an open-ended quantity of addresses for each person. What is a fairly likely scenario that would need such that a big text area cannot handle?

----  

The lion's share of programming is dealing with edge cases and exceptions. If you can't handle something like this, get a new paradigm -- or a new database model. MUMPS (even forty-year-old legacy MUMPS with all-uppercase eight-character variable names and a hard limit of 8 kilobytes per routine) eats situations like this for breakfast.