Constraints

Constraints are a fickle thing. The right constraints can create excellence, the wrong ones simply annoy, confuse and even harm us. Designing and developing software means living in a world of constraints. Constraints that you must live with and constraints that you place on your users. Constraints are often controversial and usually mean a loss of choice, but at the same time they can also provided freedom and spur creativity. What’s the difference and how do you know that the constraints you live in are helping you and not hurting you? How do you know that the constraints that you’ve place on your users are beneficial and not harmful?

We just got done throwing one of the best conferences that I’ve ever been too this past weekend in San Francisco. It was the first conference that GitHub has ever put on and I would say it was a rousing success on many fronts. One of the most consistent piece of feedback we received about CodeConf is how much people liked the size of the event and that they didn’t want it to get any bigger next year. People also loved (myself included) the single track format. These are great examples of constraints, but it’s not always obvious that self imposing limitations is a good thing. The key is knowing which constraints to pick so that you can maximize other freedoms.

Sometimes we love our constraints. Ruby and Rails are great examples and have probably been discussed to death on the merit of their opinionated designs. Convention over configuration and opinionated frameworks free you to focus on other things and release you from worrying about low level details. I love that my iPhone has a single home button instead of home, back, search, etc. There are so many other examples: 140 characters on Twitter, 50 followers on Instagram, attendee caps at conferences, 1 and 5 minute lighting talks…

Sometimes we need our constraints. Constraints often provide focus. They create a box to explore. They free up our mind to be creative. Limiting the number of attendees at CodeConf created a much more personal event and a chance to better connect with other coders and even the conference speakers. Requiring a certain amount of reputation on stackoverflow before you can comment, down vote or up vote (and deducting reputation for these actions) creates a much more functional community than traditional Q & A sites. Many extremely successful products come from embracing constraints.

Sometimes we need to break out of constraints. Often these are the non-obvious or unspoken constraints that we have placed on ourselves. Or the “we’ve always done it this way” constraints that are just waiting for someone to ask “why?”. Sometimes constraints hold us back (like fear) or might even be slowly killing us (like being unable to give up smoking). Sometimes we are afraid to try something new. Other times we aren’t even aware that we’ve placed ourselves in a box. These must be fought against at all cost and usually (but not always) they require outside perspective to elucidate their existence.

I think that you need to be self aware about what constraints you are choosing to live with and what constraints you are choosing to pass onto your users. It often helps to work with new people and see things from different world views. The status quo is always worth questioning and you will never get 100% consensus about a particular design decision so don’t ever try and please everyone. There are certain people who are really good and walking the line between constraints that amaze and constrains that disappoint. Find them and listen to them - they tend to be passionate and proactive.