A couple weeks ago, I trekked through another Toronto snowstorm all the way up to the Canadian Film Centre. Normally I’m a downtown snob and don’t go north of Bloor, but I made an exception this time because my friend Geneviève was demoing a project at the CFC Media Lab.
A Hierarchy of Needs for Design
While I was there, I happened across a copy of Universal Principles of Design. It’s a really cool book which describes 100 design principles: from general-purpose concepts like Ockham’s Razor and the 80/20 rule, to specific techniques like Iconic Representation (“the use of pictorial to improve the recognition and recall of signs and controls”). It’s kind of like a universal set of design patterns.
I only had a chance to flip through the book for a few minutes, but I really liked what I read. And Donald Norman recommends it, for what it’s worth.
One of the principles that I really liked was Hierarchy of Needs. Inspired by Abraham Maslow’s famous psychology theory, the authors proposed a Hierarchy of Needs for design:
A design must serve the low-level needs (e.g., it must function), before the higher-level needs, such as creativity, can begin to be addressed. Good designs follow the hierarchy of needs principle, whereas poor designs may attempt to meet needs from the various levels without building on the lower levels of the hierarchy first.
What about the code?
This got me thinking about coding. As a programmer, you are designing not only the product itself, but also the code. For the end product (the software that you are producing) the Design Hierarchy of Needs can be applied. But what about the code? What would a hierarchy of needs for code look like? Here’s what I came up with, but I’d like to hear what everbody else thinks.
Keep in mind that this is a hierarchy of importance, with the lower levels being more important. It’s most definitely not a sequence of steps.
- Functionality: If your code doesn’t work, there’s no point in optimizing that inner loop, or refactoring it to be infinitely flexible.
- Reliability: Any software developer worth his salt knows that there’s a big difference between code that “works”, and code that is ready to be shipped. After your code is functional, you need to make sure that it is reliable. Run it through your unit tests, run it overnight, run it on grandma’s computer.
- Maintainability: Can other people understand the code? Can you understand the code? When bugs are discovered, you need to be able to fix a bug and be confident that you won’t be causing more bugs in the process.
- Extensibility: Is your code adaptable to meet new requirements? If your code is extensible, you will be able to grow and adapt your software to meet the changing needs of your customers. If not, you might have to throw it out and start from scratch.
- Elegance & Efficiency: If you are sure you are meeting the other levels of need, then and only then should you worry about making your code fast and beautiful. Unfortunately, many people get hung up on this level instead of focusing on the more basic needs.
What do you guys think? Anything you’d change about it?
Related: Andrew McKinlay wrote about A Programming Hierarchy of Needs, and Oliver Steele proposed The Programmer’s Food Pyramid. Kathy Sierra, whose blog Creating Passionate Users I sadly miss, also tackled the user hierarchy of needs, and asked What comes after usability?