I’ve recently moved into the first place of my own, so I’ve become well-versed in the culture of Ikea furniture and the art of flat-pack assemblies. Even though the home DIY genes do not flow through my family line, and my attempts at woodwork at school were poor to say the least, I must admit to getting a certain pleasure from building self-assembly furniture and the results are, in my humble opinion, pretty damn good considering.
So what has this to do with software development? Well, I’m always looking outside the IT world for programmer inspiration and I had a moment of bizarre clarity while screwing together the parts of a dining room chair. As you do.
We, as developers, are always (hopefully) trying to find ways to make our work easier and of better quality. In an ideal world, we seek elegance, simplicity and usefulness. Things should be repeatable consistently, they should do the task at hand well, and should be easy for our users to use. And our ivory towers should be furnished by inexpensive yet stylish items.
My moment of clarity began with the Ikea instructions for the chair. They offer clear details on how to go through the instructions, what you will need and what to do if it goes wrong. So what? Well, they do this without words: clear, simple, multi-lingual instructions. From a set of simple pictures, I know what additional tools I will need, the parts I should have in the box, I know to take it slow, remain calm, and give my local store a call if things are missing or it all goes horribly wrong. All from pictures. Can you imagine having to a) write down all those steps and b) repeat in dozens of languages? Can you imagine how many more pages you would find in those instructions?
Each of the build steps are equally clear and pictorial. The minimal amount of information is used to illustrate precisely what is required at every step of the process. When writing documentation, particularly user documentation, we can learn a lot from this. It’s so easy to write a big blob of text, slap together some full-size screenshots and call that a doc. It probably makes sense to us, since we wrote it – but does it make sense to someone else? Can we strip down the information to the essential minimum? Can we make the document clear and unambiguous? Can we show rather than tell? Are we repeating ourselves? Think about these things next time you write user documentation, detail a build process or comment your code.
Make It Easy
Ease-of-use isn’t just something we apply to anything user-facing. We don’t have lots of spare time these days and much as it’s an interesting intellectual exercise to work through a lot of hassles to get something to build or install, I’m a huge fan of things that Just Work. There are few things more tedious than having to wade through shark-infested waters or find specific versions of libraries just to run a simple application or fix a bug in the source code of a third-party tool.
Ikea’s furniture makes it a doddle to assemble. Using a minimal set of tools, anyone who can grasp a screwdriver and bang in a nail (straight is optional) can build decent looking furniture. I know, I’ve been there. The barrier for entry is low, and they’ve designed the items in such a way that it’s difficult to go wrong: the clear instructions are coupled with parts that have obvious ways to fit. If you find yourself forcing parts in with brute force, or a screw is not tightening up correctly, or bits are mis-aligned it’s likely down to user error. Complicated parts, like the back of the aforementioned chair, come ready assembled so a DIY dolt like me doesn’t have to worry: someone else did the hard work.
Ikea keeps costs down by operating the Good Enough principle. I see similar bits cropping up in various products (good reuse), hidden parts have little or no finish compared to visible parts (why waste paint or varnish?), the materials are often good enough for the job at hand, and there’s a minimal theme to parts anyway. My coffee table cost 8 quid and has a mere five bits to it, yet looks great and is fully functional. It’s a classic example of a design that meets the minimal requirement to get the job done.
Professional pride often means we take longer than we should in order to do “a really good job” when really we should aim to be good enough. I’m not expecting that table to be handed down to future generations, and the designer already knew that. As their customer I wanted something cheap and available to rest a mug of drink on in the evening. I didn’t want to wait several months for a master craftsman to build me a one-of-a-kind at great expense, especially if it might not actually be what I really wanted.
When writing code, take a good look at what you’re implementing. Is it a prototype? A demo? Is it going to last a year? A decade? Are people okay if it is rough around the edges or is it a life-critical system that has to work no matter what? Use the appropriate amount of time and effort to meet the requirements, and no more. Don’t add features you or the customer may not need – the cost of my table would’ve gone up a lot if the designer had started adding drinks holders, a cactus pot plinth, customisable colour panels and so on just in case I might need them.
Finally, comes support. No matter how busy and understaffed the employees were (sounds like my office), there was always someone available to offer a hand where possible. You could interrupt them shifting crates or obviously fretting about dealing with lots of problems, but they made the time to help where they could. No matter how much of an irritating or clueless customer I could be. The warehouse could be on fire or buried under an avalanche, but that’s not the customer’s problem – the customer is trying to find his five-part coffee table and that’s the only thing happening in their world right now. No matter how overworked we are, the people using our software remain important – we’re creating code to scratch their own itches, solve their problems, create software that is of use and interest to others. Without them, we’re writing for one and that’s not so fun. Well, to me maybe. Don’t forget to make time for them.
I’m sure there are other things to take away from my furniture-driven experience, but you get the idea(s). So the next time you look around at something outside the programming world, have a think about what lessons you can apply from the experience to your software development. I certainly will never look at flat pack furniture in quite the same way again.