StartWithTheErrors

The agile Xtreme Programming methodology for writing code says that you should write your test code (the bits that checks for errors) before you start coding.

Using this "methodology" is like eating vegetables. You know it makes sense, deep down you can hear your body crying out for cabbage and french beans rather than carbs, but you still ignore it and treat yourself to some homemade fat chips instead.

It is natural when creating stuff, to design it "working"... then to use it in a perfect setting. But it doesn't really help make great software because life just isn't like that. An idea borrowed from XtremeProgramming is to write the tests for *what might go wrong* before you write the stuff that makes the right stuff work. For example, imagine a simple check out form. Now imagine...

0. I hit enter by mistake
0. I have a veeeeeerrrrryy looong email address
0. I don't have an email address (I'm between jobs and haven't heard of hotmail)
0. I don't have access to my email right now (imagine I'm using one of those kiosks in a service station... or I know my company email is down for the weekend)
0. My bum is on fire

Each of these and other "problems" makes the design of a simple form a much subtler process.

It's very simple, like ParanoidAndroid, just imagine all the things that could go wrong (and worse) to go wrong and design from there. If, as you go you create some form of UnitTest then, much later in the design process have a heap of tools to help you work out usability of even technical bugs.