Writing software and trying to break it both require different mindsets. The creative process starts with a simple goal in mind. Let’s say your app accepts email, but you’d also like to accept attachments. You’re not even building an all new feature, just making a relatively simple change to an existing feature.
Your app already supports file uploads, so you just want to extend that functionality so that people can send in attachments with their emails as well. Of course, it starts off simple. Accept the attachments and then process them. You wire some things up, and it works. A couple of test emails, and voilà. You maybe test some different file types. They all seem to work well enough.
At this point, you might think it’s ready for beta testing. Unfortunately, it’s not. This is just a prototype. Before getting too excited, you need to sit down, turn off creation mode and put yourself in a breakage mindset. When you’re excited about shipping something new and thinking about some edge cases while you’re building, you’ll invariably be thinking inside of the box. It’s important to try and imagine the bugs that you may not even be anticipating.
So, let’s start thinking about breaking things. Ignore the code that you’ve written, and start thinking about what people really do with email. Start thinking about things that could go wrong.
- What happens to attachments from signature files? Company logos and the ever-helpful “Think before you print” reminders. Just attach them? What if those attachment files put the attachments over the limit? How do you choose the files to upload?
- What about those limits? Can someone send in 10 attachments? If they do, does the whole email fail, or do you pick some out based on whatever your maximum limit is?
- What about email client behavior? Have you just been testing with your normal email client? Did you try sending email from a PC? A mobile device?
- What about quirky filenames with non-standard characters?
- What about corrupt files? Do you gracefully fail when you can’t process a file?
- What happens when there are two files but only one is corrupt? Do you reject the entire email?
- What about adding attachments when replying to an email as opposed to sending a new email? (In that scenario, the previous emails sometimes come through as HTML files.)
- When you email error messages back to the sender, do you try to send the original file back or just tell them the file name? (Imagine if someone snapped off six screenshots all with filenames like “Screen Shot 2014-02-05 at 11.24.21 AM” The file name is borderline useless, but they could always login and view the files that were successfully attached.)
Ultimately, it’s thinking through and polishing these edge cases that determines whether a feature is really done. Especially with something like email where you don’t have a web interface to immediately communicate error messages, you have to polish the edges, and there’s no way that you can think through all of the edges when your mind is in creation mode. You might be able to recognize a couple of potential problems, but not enough.
No matter what you’re building, setting aside dedicated time to thinking about how you can break it is a key part of the process. No solution mode. No find and then fix. Just find and create issue. Find and create issue. Find and create issue. Even if you only set aside 30 minutes or an hour for breaking time, you’ll see better results.
Imagine not addressing some or all of these cases. Attachments will be lost. They might be quietly discarded. Other times, the wrong attachments may be chosen. The end result is that people won’t feel confident trusting this great new fancy feature. But addressing these kinds of edge cases before your customers encounter them can not only make their (and your team’s) lives easier, but it can increase their confidence in your software. That means fewer bugs and interruptions when you begin working on that next feature.