Author: Rob Swan
Many moons ago, when I was an undergraduate, I worked as a video game functionality tester in Brighton. There was a lot of pizza and late night gaming involved, but amongst all of the fun I saw the repeated mistakes of many, many developers and it taught me a core concept:
“Learn to visualise all possible design scenarios”
The easiest way to explain is always by example. I recently wrote a new login class for one of our in-house products. The first question I ask myself in this scenario is “what does my login class need to do?”
It’s tempting to think that a login class consists of just three elements:
- Allow the user to register
- Allow the user to login
- Be able to ascertain whether or not the user is logged in
However, if you leave your list as short as that then you will have failed to cater for a number of possible design scenarios – and that’s precisely where so many developers trip over. My list looked more like this:
- Allow the user to register
- Require email validation for user registration to prevent abuse
- Allow the user to login
- Be able to ascertain whether or not the user is logged in
- Allow the user to update their essential details
- Ensure that passwords are stored as an encrypted hash and not in plain text
- Provide a public tool to allow for passwords to be reset based on username
- The password resetting tool should require email validation before resetting to prevent abuse
- Provide an administrative tool to allow the manual updating of users email addresses
- Provide an administrative tool to allow manual searching of usernames
Part of being a good programmer is pre-empting these scenarios before they happen, and being able to see the number of complicating factors that makes my list longer than you may think it needs to be.
For example; storing the md5 hash of a password rather than storing it as plain text means that a ‘forgotten password’ tool needs to ‘reset’ passwords rather than just emailing them out, and it’s this change in functionality that means that the tool needs to protected from abuse.
There’s also a very good reason to provide the functionality of points 9 and 10 in my list: if the user forgets their password and has changed their email address then the site administrator is going to need to manually search the list of users and update their email address. This scenario might seem far-fetched, but if the information in the user’s account is valuable then it’s a distinct possibility.
Not every login script needs to be as fully fledged as the one that I just wrote, but if you start writing something that lacks a piece of core funcionality which is later required then you may end up repeating work that you’ve already done and throwing out code that you spent valuable time writing.
Learning to visualise all possible design scenarios saves valuable time. It also invariably leads to better, more functional code, which in turn leads to happier users and satisfied clients.