Maslow's Hierarchy of Needs of Software Development
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:
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.
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.
About Newsletter
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.
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. :)
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.
http://www.amazon.com/Acts-Apostles-Mind-Over-Matter/dp/192975213X
Need permission to use it in my presentations . :)
http://dubroy.com/blog/a-hierarchy-of-needs-for-code/
Cheers and keep up the great work.
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.
There are basic needs that have to be addressed before talking about building "good" software.
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
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.
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).
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.
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.
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
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
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.
I should be able to spin up a new project and be at level 3 without having to think hard about it.