You know that story about how NASA spent millions developing this pen that writes in zero-G? Did you ever read that? And how Russia solved the problem?
-Yeah, they used a pencil.
Although not based in fact, this urban legend demonstrates how problems often have an overlooked simple solution.
When building Barometer I could of added a password field, so that a user could login and change their recipient email address. It is easy to think this would be quick to implement.
The Fisher Space Pen
- Initial account creation validation i.e. passwords match
- Email address validation to ensure the forgotten password function will work
- A login form
- Forgotten password link/page
- Reset password function
However a simple solution already exists. If a user wants a Barometer feedback tab to send to a different email address they just create a new one. Sure this is going to lead to a few extra rows in my database, but this is ‘cheap’ in comparision to my time.
My ‘signup’ form is one field long; your email address. I joke that the signup only takes ’3 seconds’. This ultimately comes to the same thing as creating a password field, but simplifies the codebase greatly, and removes a barrier to signup for my user.
37 Signals make a very interesting point in the chapter Start with No of Getting Real:
Each time you say yes to a feature, you’re adopting a child. You have to take your baby through a whole chain of events (e.g. design, implementation, testing, etc.). And once that feature’s out there, you’re stuck with it. Just try to take a released feature away from customers and see how pissed off they get.
Adding a new feature makes your codebase exponentially more complex, and once added it is there for good. Starting from a ‘No’ position makes you really think and consider a feature’s implications. Often I find there is a simpler way (the KISS principle) to solve the problem, or given the extra work involved in implementing the feature, it is just not worth it.
