Home » Featured, General Computing, Headline, Web Development

Maslow’s Hierarchy of Needs Applied to Software Development

1 September 2009 14 Comments
Maslow’s Hierarchy of Needs Applied to Software Development

Maslow’s hierarchy of needs is a theory in psychology which attempts to classify human “needs” in order of importance ranging from low to high. The lowest needs being the ones most fundamental to life, the highest being the most aspirational or transcendent.

The hierarchy of needs is arranged in a pyramid, once lower level needs are met you can move up to the next level. Lowest on the pyramid are things like Food, Sleep, Water. Here’s a visual:

Maslow's Hierarchy of Needs

Self-actualization is highest in the list and presumably by the time you’re operating at this level you’re ready to transcend these earthly bonds.

I did a simple thought experiment to try to determine how this would work in a software development team. Software can suffer from very basic needs such as lack of disc space, or sufficient air conditioning. You might laugh but I’ve been in the office at 4AM when the A/C is off working on production releases with a team of developers. It’s not fun. On the contrary, a well setup team doesn’t worry about these things, they’ve moved up the pyramid. This got me thinking, what sort of pyramid do you need in order to operate as a “highly effective team”. How much of the pyramid do you have already and what are the gaps?

Here’s what I came up with (click to view)
Shanahan’s Maslow Hierarchy

My analysis is by no means complete but I ended up with Seven levels. Seven’s a good number. They break down like this:

Level 1 – Physical Needs
These are the basics that every developer needs in order to do some work. A Compiler, Computer, Desk, Cube, Coffee, Lights, Air Conditioning, Team Structure (folks need to know who to talk to), Project Schedule. No surprises there. I’ve included a box for “Google” which represents internet access. Yes, I have seen teams that are asked to code whilst lacking internet access. Can you imagine ramping up without reference material? I’ve also included Software Licenses because some shops develop using trial licenses only. Lastly, Whiteboard and Markers go a huge way in terms of communication. Of course this list could be much longer but I stopped there.

Level 2 – Tools
Level 2 looks at “tooling”. You have a compiler but level 2 adds in productivity features like Intellisense. A Quiet Office w/door is vastly superior to a cube (in some cases, not in others). Code is managed in a Source Control system and Coding Standards are documented. Requirements might be capture in MS Word but at least they are documented. Some Basic Project Management exists with maybe a weekly team meeting. Code Reviews are manual and defects are tracked in a dedicated Bug Tracking system (e.g. TFS). The team has access to Vendor Support Accounts for when they encounter problems.
Lastly, formal Environments e.g. SIT, UAT etc. are established.

Level 3 – Common Components
Ok, now we’re starting to work smarter not harder. Horizontal functions and cross-cutting concerns have been pulled out to some degree into Common Components. Typical pieces include Authentication, Authorization, UI Layer Design Patterns, Data Access, Localization, Logging and Exception Handling. A formal Build Process has been established. Non-code artifacts like Design Docs and Test Cases are managed in MS Word.

Level 4 – Re-Use / Frameworks
Taking the Components from level 3 and tying them together we get a Framework. Integrated components and Comprehensive Developer Utilities and e.g. a Data Access Layer that works together with the MVP Pattern used by the UI Layer. The pieces work in concert with the whole exceeding the sum of the parts. More like a Framework than isolated components. This in turn institutes a Consistent Architecture across projects. The Build Process is now Automated and we can start to tackle Distributed Development.
Non-code artifacts are no longer managed through Word but through dedicated systems e.g. CaliberRM, DOORS, TFS. We also begin to see higher level concepts come into play like B2B interactions, e.g. Identity Federation. These high-order concepts are not possible unless the lower levels of the pyramid are firm.

Level 5 – Automation
Now we look for efficiencies, scaling back the human processes required and moving to an automated life cycle where appropriate. Tying the various sub-systems and processes together through automation. Virtualization or Cloud Computing might enter here. Things like Code Generation and Continuous Integration are implemented and we start to see comparable Metrics coming out of the projects. Source Control is governed by Policies which enforce things like “all code must have a unit test” etc. Requirements, Test Cases, Code and Defects are all linked and we begin to see traceability through the project’s deliverables.

Level 6 – Software Factory
By operating as a “factory” the team introduces Governance around non-software artifacts. Projects are more predictable and Metrics are harvested consistently. Estimates are more accurate and justifiable leading to more achievable project timelines. Results can be Quantifiable rather than purely Qualitative.

Level 7 – Software as a Commodity
Now you’ve reached Nirvana, or almost. Projects are “Turn-Key” with a high degree of predictability, very low risk and very accurate estimates. The management team has End-to-End Traceability/Visibility and there is a complete feedback loop from Project Inception through to Live Date.

This was a useful (and challenging) exercise. If I’m being honest I would say we’re operating at level 3 or 4 right now and failing to climb higher because we keep getting dragged back to lower levels.

My gut reaction was that the smaller the team, the more nimble they can be between levels and I often envy smaller shops with less constraints and more freedom to move around this pyramid. I’m not sure that holds though since perhaps the smaller the team the more volatile the lower levels of your pyramid might be? Conversely the larger the team the more stable the lower levels would be but the tougher it is to move up the pyramid. There has to be a balance.

Given enough resources and a solid foundation I feel the pieces are out there now to rise higher, they just need to be applied.

The question now is whether “Shanahan’s Hierarchy of Software Development” belongs in Zachman? or “Popular Psychology”?


  • Joe Marchese said:

    Like your thinking… worried that you were driven to write it rather than go for a run or play with the kids, but it’s worth the read.


  • Alexander Davis said:

    This is pretty insightful. Thanks for sharing.

  • Vasantha said:

    Happy to see ‘Basic Project Management’ in level 2.. it is a function that is often invisible especially when done well.

    One thing I noticed is that the developers don’t have to traverse through the pyramid in the same way as depicted. For e.g., automation can be thought about and setup early.. I guess this is different from software development process vs. software development evolution or maturity levels.

  • Francis (author) said:

    Vasantha I had to get the Project Mgmt in there and as you can see it carries through to the upper levels in the form of Metrics, Requirements Mgmt, Traceability and so on. I do want to make the point though that you need to tackle the lower levels and get those shored up before moving on to advanced topics. There’s no point looking at automation if you don’t have the basics from the underlying levels figured out. That was Maslow’s key points that once the lower levels become unsteady we revert back to address those items before moving back up the pyramid.

  • Francis (author) said:

    You know me Joe, I would certainly prefer some rough-housing with the kids or a jog. These posts are written in the wee-small hours and then scheduled through WordPress to get published. Who needs sleep?

  • Rajesh Pillai said:

    This is a nice and simply refreshing read.

  • Advait Kulkarni said:

    Hi Francis,
    An interesting take on Maslow’s theory..a different perspective..

    Good read

  • Chibby said:

    What cracks me up / frustrates me is the companies that think they can achieve “software factory” productivity without investing the time, money and energy on basic things like tools, common components, frameworks and, yes, air conditioning.

    We have coffee, and its free, but it doesn’t taste very good. And while we have google, many of the information sharing sites that google recommends are characterized as “personal blogs” and therefore blocked by our web filtering software.

  • Francis (author) said:

    Ron you’re absolutely right, takes a fair amount of investment. Moreover though takes some leadership and sponsorship on the part of management as well as the technical know-how to be able to understand the vision. Basically it’s not easy, hence the “pyramid”. I would say scaling the pyramid is logarithmic in terms of the effort/cost/time to get to the next level.

  • Greg said:

    Well that’s just freaky…I made almost exactly the same observations a few months before you posted your insights…Well I broke down the levels of software differently….I think they are both valid..

    Would be interested in sharing other ideas.

    Check out my version:



  • Mark said:


    In December of last year I took over a small web development team (~6 people) in need of rescue. I was looking for a way to illustrate to my team and my bosses the bad state we were in and the transformation we were going to undertake during the year.

    I needed to show that things were bad but I also needed something that was aspirational and that I could refer back to and show progress with. I also wanted to show that there was an orderly maturation that we would need to go through to turn-around.

    I was thinking about Mazlow’s hiercarchy and I happened upon your article. I re-built your graphic in Powerpoint and at the begining of the year I kicked off my the programme. We had almost everything on the first level ticked off and… well that was it.

    Now we’re at the end of Q2, we’re half way through our year and we’re climbing our way through the 3rd layer. We refer back to the pyramid at least once a month in team meetings and it provides us with an extremely clear structure of where we were, where we are and where we’re going all in one picture.

    I thought it was about time I said thanks.


  • Francis (author) said:

    Wow, thanks for the great comment! Always great when two schools of thought (software and psych) can cross-pollinate. This made my day.

  • A hierarchy of project needs | Schneide Blog said:

    […] not the only one with that idea. For example, Scott Hanselman blogged about it in 2012, and Francis Shanahan came up with an extended version in 2009. Both adaptions are reasonable and stand on their own – I don’t want to invalidate or […]

Leave your response!

Add your comment below, or trackback from your own site. You can also subscribe to these comments via RSS.

Be nice. Keep it clean. Stay on topic. No spam.

You can use these tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This is a Gravatar-enabled weblog. To get your own globally-recognized-avatar, please register at Gravatar.