Scott Hanselman

Maslow's Hierarchy of Needs of Software Development

January 28, '12 Comments [28] Posted in Musings
Sponsored By

I've been experimenting with my diet a little and considering a Paleo diet. What an amazing and selfish thing, though, for me to even consider or be able to change my diet in a fundamental way. Only someone who isn't worried about their next meal could explore that aspect of their lives without fear or concern.

One doesn't get to have certain luxuries until other more basic needs are met. Here's an interpretation of Maslow's hierarchy of needs:

 

Maslow's heirarchy of needs, as a pyramid

I was talking to a customer a while back and one gentleman was deeply concerned about coding style, curly brace location, best practices in interface design and a bunch of important but arguably not urgent thing. Their unit testing wasn't well organized, their deployment was manual, their build was only marginally verifiable.

Stated differently, he was asking questions like "Am I eating enough veggies rich with Vitamin A" without asking the more fundamental "Do I have food for tonight?"

Now, apply the Hierarchy of Needs to Software and Technical Debt. Here's one, with my thanks to Phil Haack, Jon Galloway, Jonathan Wanagel, Paul Stovell for their help in brainstorming.

A proposed heirarchy of needs of software - Bragging Rights, Refactorable, Maintainable, Buildable, Revisable

Bragging Rights - Change you are proud of

Paul put it well when he said to me: "The top of Maslow's pyramid is self-actualization...in some ways I think we like to achieve self-actualization through our code, [such that] in years to come, maintenance programmers will stumble upon this architecture and exclaim, 'Wow, Scott was here.'"

Are you writing software or crafting software? When does your craft become art?

This is a noble and certainly attractive goal, but is one that should be attempted only after the basic needs are met.

Refactorable - Change without fear

Is your code/system easy able to be refactored? Can you rearrange it without fear? Does it follow all the conventions and use the appropriate idioms of your chosen language? Do you have automated unit tests?

Maintainable - Change with verification

Is it able to change at all? Are bugs fixable? When you make a change is that change verifiably correct? Any tests at all?

Buildable & Deployable - Change in production

Can you deploy your system as easily as you can build it? Continuous Integration is effectively a must in today's software systems, but moving up in importance is Continuous Deployment - with rollback!

Revisable - Change

Is your system in source control with a clear workflow that governs contributions? Can you revert changes, stamp official changes, branch and merge? What? You're using zip files? Sorry, friend, you don't get to talk about class design or move around UML diagrams until you're using source control.

The importance of leadership

This underscores the importance of a strong and appropriately self-aware leader. Creating art is the fun stuff but it isn't always what needs to be done to move the project forward. The tech lead needs to recognize the right time to be an artist and the right time to invest in strong foundational processes.

Are we eating enough leafy greens as a team? Let's start with "are we eating tonight?" and work from there.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web
Saturday, January 28, 2012 2:39:44 AM UTC
I like it. And in the same manner that perhaps the first 3 layers of Maslow are effectively guaranteed in a developed society, the first three levels of your Software Hierarchy should be expected of any "developed" software organisation (team, dev shop, whatever).

I should be able to spin up a new project and be at level 3 without having to think hard about it.
Saturday, January 28, 2012 2:52:13 AM UTC
I like the idea, but I think this misses the mark a little bit. Maslow's pyramid starts with what is necessary and proceeds to what is ideal. Everything in this pyramid is a bit idealized.

In my mind, the base of the pyramid is "Builds and works". It might be completely shitty, but it suffices to get the job done. It's crammed with technical debt. Things get better from there. That is a better equivalent of "Do I have food for tonight", I think.
Saturday, January 28, 2012 3:03:55 AM UTC
What I miss from the hierarchy is Documentation, but that could fit into the Maintainable layer.
Saturday, January 28, 2012 3:27:22 AM UTC
A good idea, I've seen this approach used for other practices within software development. The idea has been primarily used for IT strategy and stability within organizations - however I like this approach for the individual developer.

I originally saw the idea about 5 years ago with a professor of mine at my university back in Australia when I was completing (I really should finish it one day instead of working..) my masters. I'm currently adapting the same idea for a whitepaper (which work is getting in the way of also..) that I'm writing for another area of software development. I think that Maslow's can be used generically for a lot of things we think about in software engineering.

Great, thought provoking blogging as always mate. :)
Saturday, January 28, 2012 3:51:40 AM UTC
I know it would be way off topic and away from the normal focus of your blog but at some point I would be interested to hear your objective views on the Paleo diet. I have read the book "the Paleo Solution" by Robb Wolf but have not been convinced enough yet to try it, maybe I should.
Norman Close
Saturday, January 28, 2012 5:07:57 AM UTC
I like the idea, but agree with @KevDog, we need a base, or perhaps a corresponding lower level pyramid that is the food and water bit - why we're writing the code. Perhaps something like:

Traceable - All main features are testable and can be traced back to needs
Functional - The code works and does something helpful
Resourced - We have the time, people, kit and communications we need to code.
Saturday, January 28, 2012 5:13:04 AM UTC
There's a kinda interesting cyberpunk novel who's primary theme is Maslow's Heirarchy of Needs, software, and tech companies:

http://www.amazon.com/Acts-Apostles-Mind-Over-Matter/dp/192975213X
Saturday, January 28, 2012 10:25:17 AM UTC
Nicely stated.
Need permission to use it in my presentations . :)
Saturday, January 28, 2012 1:02:12 PM UTC
This reminds me of Watts Humphrey's work on the CMM and Personal Software Process.
Michael Hurwitch
Saturday, January 28, 2012 3:31:16 PM UTC
I've seen a very similar hierarchy like this one Rob Conery mentioned once. It's a bit lower level, the base being 'functionality' which I believe to be a bit more technically correct.

http://dubroy.com/blog/a-hierarchy-of-needs-for-code/
Saturday, January 28, 2012 4:05:14 PM UTC
I like the general idea here. I do wonder though if some of the aspects like continuous deployment really are foundational. Seems a bit like a manufacturer saying we shouldn't even talk about design best practices until we're sure our shipping process is nailed down. I'm sure that's an oversimplification though and I do believe the overall message is spot on (as always) and I recognize the need in my own technosphere to continuously improve in all these areas.

Cheers and keep up the great work.
Saturday, January 28, 2012 4:13:14 PM UTC
"Basic human needs," as defined by Maslow (at least the lowest levels: are survival essentials). And, you might the see the "middle levels" of Maslow's pyramid as essentials of psychological well-being: there's nothing abstract about those either: older people whose spouses die tend to die sooner; people who are depressed, lonely, and without human interaction, are much more prone to clinical level depression, stress, and physical illness.

But, to liken "software development" to "basic human needs" I think is a "casting error" this compiler won't handle :)

From the viewpoint of the survival of the company, and its management: the base level may be: Did it ship ? Is it generating income ? Or: are we headed for Chapter 11.

For programmers, a whole different viewpoint in terms of "value," and "quality," and here's where I would turn to the ancient Greeks, particularly to Aristotle and the concept of "Arete," "excellence." But now, we speak of the "ideal."

Can great software ... in terms of marketplace recognition ... in terms of customer satisfaction with its functionality ... be an absolute mess as code ? Yes ! I've worked under the hood on a few programs from a well-known company that have generated millions of dollars in revenue for said company, and the duct-tape and baling-wire code-base reminded me of a telephone booth stuffing scene in a Marx Brothers' movie.

Does great software have to be a "mess;" ... uhhh, philosophically, I want to say: "no: it can be a truly aesthetic fusion of science, art, craft, and individual, and team, brilliance."

I hope I get to see some code like that before I discard this now aged physical body.
Saturday, January 28, 2012 6:21:10 PM UTC
I didn't study CS at university. My major is Travel Management and I am happy to see something I have seen at Management 101 class :)
Sunday, January 29, 2012 2:20:37 AM UTC
Like
John A Davis
Sunday, January 29, 2012 6:19:48 AM UTC
Scott, you changed man... having a mid-life crisis perhaps? :p
PaulJ
Sunday, January 29, 2012 9:33:54 AM UTC
@Norman, I highly recommend it check out http://www.marksdailyapple.com
cb
Sunday, January 29, 2012 8:53:30 PM UTC
Great stuff! I find everything accurate, and I live by Maslows origional Hierarchy of Needs and think its very relevant to succeeding in life.
Monday, January 30, 2012 4:14:46 AM UTC
I think I have to add a basement to your pyramid - There are some place where you program without adequate time and resource, so they work hard on whatever they come to, without the leisure of "building something according to spec.", and become what could be described as "chaotic development".

There are basic needs that have to be addressed before talking about building "good" software.
Cheong
Monday, January 30, 2012 2:17:02 PM UTC
Hi Scott,

An interesting variant of the Mazlow pyramid!

I had also published in 2011 a pyramid for the software developer himself:

http://blog.softfluent.com/2011/05/06/

Fun to see a software development version!

Keep on the good work,

Daniel
Monday, January 30, 2012 4:14:48 PM UTC
I like it a lot - I was about to make a comment similar to @kevdog... that it seems like "We got it out the door so the lights could stay on" is the base level, and as much as I despise the CMMi, thats not unlike the 'level 1 organization' attitude.

I think some of the comments are caused by a tension in that there are actually TWO different hierarchies here... The 'Hierarchy of Project Needs' and the 'Hierarchy of Developer Skillset Acquisition'... That is, what the project needs is different than what any one person's career advancement needs.
Monday, January 30, 2012 4:53:09 PM UTC
I'm not a psychology expert, but Chip and Dan Heath's book Made to Stick: Why Some Ideas Survive and Others Die suggest that Maslow's concepts aren't really a hierarchy: People pursue all levels (to varying degrees) simultaneously. (See chapter 5 of that book for more details.)

I wonder if the non-hierarchical version still applies. A developer could be using a version control system but not making use of continuous integration. The software design may be flexible enough to handle the most probable types of change (but not all types). The software may meet the end-user's needs perfectly and look gorgeous, but the code underneath it is a mess.

All of the levels you (or others) have proposed have value. My opinion is that they're not so rigid (i.e., you cannot move to Stage 2 without completely satisfying Stage 1).
Monday, January 30, 2012 10:40:31 PM UTC
The other levels seem practical. The one at the top looks like it could use some refinement. Bragging rights. If you wrote it, you had better be somewhere unreachable for questions. When I look at legacy code, as in a year old, the only thing that comes to mind is why was it done THAT way?! Next, I look in source control history to see who did that and wonder if there is anything to learn from the developer's style worth using again. After a while in large systems code becomes code smell. When it was new it may have been the coolest, best practice way to do things. After a while it gets stale and gross like a cheese left in the refrigerator too long. Some kinds of cheese get better with age and many others do not. It's best to forget who wrote that code a year ago and focus on your job as a maintenance programmer to refactor it. (Have you ever been a maintenance coder, I wonder). Can we as developers consider a different kind of bragging right? That of improving peoples lives? I look around and see folks going for code bragging rights instead of focusing on WHAT they are building. The point: Make code that ages well in software that people can benefit from using. Then you can simply say with confidence, "I was part of making that."
inTheTrenchesDev
Tuesday, January 31, 2012 12:37:21 AM UTC
Other ideas I had for the top of the pyramid were vanity, ego, and pride. Thoughts?
Scott Hanselman
Tuesday, January 31, 2012 2:55:13 PM UTC
Great article - I've already printed and annotated the triangle to share with others.

I think this pyramid provides a triage list for software projects - that is, what needs to be fixed first. Don't waste time on formatting the source code if it's not in some revision tracking system, for example.

Also +1 for Paleo. My wife's been on it for three months, and I've taken it as my new year's resolution for 2012. Give it a try.
Chip Beauvais
Wednesday, February 01, 2012 4:14:22 PM UTC
Agree with other commenters: the idea is great, but the result doesn't really jive with Maslow's concepts. We may not like to admit it, but there is a huge amount of software that is written and deployed today that we would consider an absolute mess, but still performs a useful function. THAT, sadly, is the "next meal" at the bottom of the pyramid. Everything in your pyramid would effectively be in the top 3 levels of Maslow's pyramid.

It's not just an idle revision either; in order for the pyramid to be meaningful, a person (dev team) needs to be able to identify where they are on it. Most dev teams I know of couldn't even find themselves on the pyramid as you have presented it. We need to identify all the levels that need to be traversed between the (sad) state of most "professional" dev teams and where your pyramid starts.
Monday, February 06, 2012 2:04:24 PM UTC
Hi Scott,

I also published in 2011 a Mazlow pyramid for the software developer himself: fun to see a software development version!

Keep on the good work,

Daniel
Wednesday, February 08, 2012 6:16:46 PM UTC
http://www.surveymonkey.com/s.aspx?sm=p5rXLSA_2b35zbk8dqM5QqPQ_3d_3d

Hi, I am a Type 1 diabetic and was diagnosed at 9 months old and am doing some research on hypoglycemia and would like to see if anyone would be willing to take this survey above so i can gater some information about my report.

I would really appreciate it,

Chris
Chris Alfano
Monday, February 27, 2012 6:41:55 PM UTC
I came to this blog, via google search, after our automated build had been broken for 5 consecutive days. (For bragging rights, I must disclose I was on vacation). Meanwhile, developers on our team were working on other items, rather than stopping everything to diagnose and correct the broken build. I thought to myself: is there a Maslow's pyramid for software development?

The base of the pyramid should be: Purpose. Does it have a purpose? Does it solve a problem. The next level should be: Existence. Does it compile? On top of that should be: Does it run?

In the original Maslow formulation, it is a rare psychological disorder, when the individual is not able to assess when their base level needs have not been met. Most of us know when we are hungry, when we lack shelter, when we are lonely. By contrast, in the software development analogy, it is a rare occurrence for an individual or a team to know if these base level needs are met. Continuous integration is improving this.

- Peter
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.