As designers, we often make the mistake of thinking that the product we are working on is equivalent to what the user can see and experience: the user interface and the broader user experience. Our focus, naturally enough, is on the interaction and visual design of this interface. We get very frustrated when our designs are not delivered perfectly, if developers misunderstand what we want, or if things that we have lovingly crafted are de-scoped.
In bad moments, we may be tempted to accuse developers of being stupid or lazy: the design was brilliant and the specification was perfect – why didn’t they build it right?
We need to resist these temptations and have respect for what developers do. They are very smart, talented people, just like us, trying to do their best within the eternal limits of time, budget and quality. If you take the time to lift the lid and look in more detail at what they actually have to deal with, you might just find a new appreciation for them.
The first thing to realise is that code is like an iceberg: the vast majority of it (at least 90%) is ‘below the waterline’ – not contributing directly to the user interface, but managing databases, business logic, networks, and a hundred other things that are essential to making the overall product work. Building this code is what takes the vast majority of the time and where most of the complexity lies.
Developers also have to worry about a host of things that you don’t know about (and really don’t want to know about). Examples include performance, security, network capacity, load balancing, data backup, migration and backward compatibility. This stuff is not fun and nobody gets a prize when it works well. But people certainly notice when it goes wrong. Take a look at Six things I wish we had known about scaling by Martin Kleppmann for an eye-opening taste of these kind of issues.
Another thing to appreciate about developers is that they are faced with a stringent test of their capability almost every day. Perhaps the most stringent test faced by any profession. Every time they submit their code, it has to run. This means that they have to continually create code that is a 100% complete version of a proportion of the functionality that is needed. It’s not possible to fudge it, there aren’t any shortcuts, and it really is possible for a single misplaced bracket to break the whole program. Bear that in mind the next time you are showing a developer a sketch on the back of an envelope, or providing them with a wireframe full of Lorem Ipsum text.
Don’t get me wrong here, I’m not suggesting that all developers are amazing and all designers are slack. There are good and bad examples of both. I’m also not suggesting that we need to transform our deliverables into 100% complete specifications – there are good reasons why this wouldn’t help. What I am arguing is that a better appreciation of what developers do and the problems they have to deal with will make us better designers, better communicators and better team players.
Martin Colebourne 