My friend and collegue, Mike Phelps (think software, not swimwear) came up with this mantra and I still use it frequently.

NONE

When writing code, ask yourself how it will perform if you get back nothing.  Are you checking for and handling nulls?  Too often developers expect results back and get Null Reference Exceptions when they don't.  This should be a completly expected occurance.

ONE

What if you get back 1 item, or record.  How will you display one item at a time.

TWO

What about multiples?  How are you going to handle 2 addresses for a person? If you are expecting only 1 phone number and get back 2, how will your code or UI respond.  Do you need 2 methods to retrieve data?  One that returns an item and another that returns a collection?  Is your SP *smart* enough to just return 1 record?  If so, how will it repeatedly know which 1 to return?  Is there a primary flag on the record or do you just return the original or do you return the most recently added, or edited.

TEN

What about 10 items?  Do you have a plan in place for listing out a sizable amount of content?  Will you be paging the data?

TON

How will your application scale?  What if you get a TON of info to work with?  At a certain point, you can't return tens of thousands or billions of large records from the DB into memory.  You can't load a TON in to your session.  You also can't always return it all to the browser in a grid.  Will your bandwidth and memory support this scenario?

Have these conversations early with your business users and work those guidelines into your code.  If they say an app will *never* run into that problem, then simply document that in the code.  Note that logic was omitted because there was not a business need for it.  Should the need arrise later because of unforeseen success or repurposing of the app, make sure that the comments provide guidance on how the code can be altered to adequately handle it.

By approaching your code with these common questions, you will find a common pattern evolve.  Similar code will respond the same and the user experience will be much more consistent.  The best benefit to the Developer, though, is that you have addressed the a common source of bugs before it materialized.