a Maslow hierarchy of software making

18 March 2014, 10:50

This morning, I whipped up a Maslow hierarchy for breakfast, one for the activity of software making:

the Maslow hierarchy of software making

My thoughts started where one normally starts explaining the hierarchy: at the bottom. I recalled what I wrote here a while ago:

‘Everyone knows that in order to get software, it needs to get built, i.e. code developed.’

And with that I had my first, ‘physiological’ level of software making: to build. Without it, there is nothing. This is the hammer and saw level; just cut it to size and nail it together.

You would be surprised how much software is made like this—yes, also for top dollar.

moving on up

The next level is to engineer. At this point one is not just cobbling code together, there is also thought and structure involved, on a technological level. This is all about avoiding chaos, being able to scale up—in size and complexity—and code being maintainable in the future.

We can use these two levels to illustrate a common source of strife in software development outsourcing. The customer thinks they will get an engineered solution for their money; the supplier thinks they can just build whatever passes the acceptance tests.

Maslow’s second level is called safety. Somehow that matches quite well with what software engineering is about.

a giant leap

One level up is a whole new ballgame: to plan features. This requires having a product vision and picking only those features that make the product stronger, while saying ‘no’ to 95% of the features that users, marketing and engineering come up with.

This is the entry level for putting some purpose into the activity; to make software that matters. It is not easy to make it up to here; respect for those who do. It takes a visionary person, confident enough to deal firmly but correctly with all the wild impulses that come from users and engineering.

The corresponding Maslow level is called love. Indeed, to plan features is the first step of putting some love into the software you are making.

accident prune

The fourth level is to take the random factor out of software making: to specify. Define first what needs to be made, before engineering figures out how it can be built. This roots out the standard practice of the how determining what the result will be.

I am totally not a fan of heavyweight, bureaucratic specifications. Just keep in mind: the point is that a project should be able to tip the code, swap out the complete engineering crew and be confident to resurrect exactly the same software from spec—just with different bugs.

full potential

And now we reach the top, the level of complete product realisation: to design. The focus moves to product value delivery, by addressing user needs, while taking into account what is feasible with technology.

A software project that is operating smoothly on all five levels of the hierarchy is one that is delivering its full potential. It can concentrate on realising its vision and through that be a leader in its market.

Conversely, a project where one or more levels of the hierarchy are missing, or not functioning well, will spend a considerable amount of its energy on trying to fill the void(s). The organisation may not quite be able to put its finger on what is wrong, but spend a lot of communication, meetings, time and action on correcting it.

Maslow’s top level is summed up as—

‘morality, creativity, spontaneity, problem solving, lack of prejudice and acceptance of facts’

That’s a pretty good trait‐requirements list for a designer. Stated the other way around, to design is a human need of the highest level.

use it

Now we can work the diagram, in true Maslow style:

An organisation will only be motivated to fix the lowest level that is found lacking.

As we have already seen, the build level trumps anything. Problems on this level—e.g. lack of developers, or ‘physiological’ bugs (crashing)—will crowd out any other considerations. Moving up, if the engineering is found lacking, then an organisation will not be inclined to take feature‐planning, specification, or design serious.

If an organisation fails to plan features then design and/or specification initiatives will be in vain. Is the specification process found lacking? Then it will be hard for an organisation to become design‑driven.

Working the diagram, we can understand how software‐making organisations act.

postscript

Here is something I noticed when I looked at the hierarchy diagram: it doesn’t mention software or anything related, does it?

Turns out the diagram is general for any design discipline; it is a Maslow hierarchy of making anything.

Labels: , ,

PS logo

0 comments · post a comment

If you like to ask Peter one burning question and talk about it for ten minutes, then check out his available officehours.

portrait of Peter  Peter Sikking is an experienced
interaction architect. He unabashedly puts shipping great products at the centre of his design practice. He is known for his work for Google, Nokia, the Metapolator & GIMP open source projects, and startups.

Peter teaches, mentors, lectures and publishes. He enjoys working with small teams in an international setting, but also the fact that his work can be found on half a billion mobiles and creates billion‐dollar revenues.

What is Peter up to? See his /now page.

get in touch: email · twitter · g+ · linkedin · xing