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

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 HaackJon GallowayJonathan WanagelPaul Stovell for their help in brainstorming.

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


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.


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?


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


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!


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.


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.


Leave a Reply

Your email address will not be published. Required fields are marked *

Post Navigation