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.

What if we applied this similar theory to Software Development !

While digging on internet, I got one very interesting thing written by ‘Shanahan’.

He applied ‘Maslow’s Hierarchy of Needs’ to ‘Software Development’.

Concept is taken from original famous ‘Maslow’s Hierarchy of Needs’ as shown in image

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.

taken from: http://francisshanahan.com/index.php/2009/maslows-hierarchy-needs-software-development/

Be Sociable, Share!

•