There’s a great line from the start of “Pirates of the Caribbean: Dead Man’s Chest” spoken by everyone’s favourite pirate Jack Sparrow.

Complications arose, ensued, were overcome.

If only it was that easy. It is never that easy. When complications do happen, are we making things complicated for ourselves?

I do. I make things ridiculously complicated sometimes when I’m writing code. I’m always thinking too far ahead. What if we need to do this, what if the format changes? I’m always thinking of edge cases for features that won’t be encountered on a daily basis. I find it quite a hard habit to break.

Take for example this form I was working on yesterday. It required three things:

1. A question
2. Your email address
3. A list of other email addresses

So handling the first two things is easy, but I wanted to do something smart with the list of email addresses so that people could input any number of email addresses. I ended up with a form like this:

Handling the code to add and remove the email addresses from the list wouldn’t be too difficult but it’s clearly not the easiest thing to do. Annoyed at the complicated form I would need to build, I left my project to do some client work that had been scheduled in.

Then it hit me that night. What else uses lists of email addresses that are not constrained by size? When you are writing an email you simply enter the names of the people you want to send the email to. In one textbox. It’s that easy. The next day I changed my form to use a single textbox for the list of email addresses. A complicated form made easy.

Two things I took from this:

1. Keep it simple stupid

The KISS principle is a recurring topic in software development, but we developers tend to think of the YAGNI (You aren’t gonna need it) principle. The two are similar, but what I need to remember is the simplest and stupidest way is always going to work. It might not be clever, but as long as a simple design works, we should use it. If the simple design can’t handle an edge case in the future we can fix it then. There’s no need to worry about it for the moment.

2. Look to other examples

When building software, there’s no shortage of examples that you can refer to for influence. I’m not suggesting that you take a straight copy of a unique feature for another product, but when designing processes for your application, it can help to look to other examples to see how it is handled already. It’s probably going to be simpler than you first thought. I didn’t even think to initially look towards other examples of how this could be done. I could have saved myself a lot of time.

So there we go. My complications were not as quickly overcome as Jack Sparrow’s complications, but then he doesn’t write code does he?