Introduction
First, thanks for reading! This is my first post here on Dev.
If you aren’t familiar with Malsow’s Hierarch of Needs here's a brief explanation of the theory. There's a hierarchy of what a person needs, and they need to have all the things on one of the tiers before they can start fulfilling the needs on the next tier. Without having your basic physical needs satisfied, you can't have your higher-order needs fulfilled.
What do you need in application?
Let’s take that and apply it to applications. Let’s assume that you can only have one of the following before you can add another:
- Performance
- Documentation
- Tests
- Readability
- Maintainability
- Functionality
- Security
- Accessibility
I think that I would probably go in the following order:
- Functionality--the app should work, right?
- Readability--hopefully a person can read the code.
- Maintainability--the code should be easy to maintain. This falls in line with readability, but has more to do with organization.
- Security--the application should be secure and follow basic security principles.
- Accessibility--the application should be accessible to ALL users.
- Documentation--the code, as well as any user documentation, exists and is valid.
- Tests--the application has automated testing. This is my passion and it makes me so sad that this falls so low.
- Performance--the application is performant.
Your Turn
How would you rank them?
What would you add?
What is missing?
How did you decide your order?
Top comments (4)
Interesting way to look at some important topics in application development. Although it sometimes differs per client and use-case, the general overview you have does make sense. It captures some dependencies between topics (e.g. readability before maintainability).
Depending on your client(s), it might help showing in which order issues are tackled by the engineering team (e.g. performance is lower than security). And it can be used to indicate priorities for team, if your team has a shared pyramid.
Gonna crack my brain a bit more on it, but it got me thinking
I also think that the type of applications you work on make a HUGE difference as well. For the most part, I work on server side applications and services in C#. I added accessibility because I think that it is extremely important, but if you are working completely in the server, it's not super applicable.
I'm also biased towards security because I work for a HIPPA compliant company, so that is something that we have to have drilled into every app.
Finally, at least with service side stuff, performance can be bought. If something is slow, there are many instances where you can just get a bigger box to speed things up. I know that is the worst way to look at it, but there is some truth to it.
Completely agree. It really depends on the application and on what parts you (and the team) are working on.
Myself I am more of a front-end guy, but work and lead a team that does the entire stack. From React front-end to .NET Core micro-services on Azure. My expectation would be that the order would slightly differ for the entire team, compared to your view. But the front-end view would even differ some what more.
On the other hand, it also depends on how you can implement. On the front-end you could put a lot of effort in 'perceived' performance by implementing optimistic UI. But something like that has other big downsides (e.g. it is a lot harder on big applications that have a poor maintainability). In the dependencies, how you apply them weigh more heavily down the line. Personal preference would influence it only a little I feel.
I'd mostly agree, with a couple of notable changes:
Security goes higher, as having that consideration earlier is more likely to impact future work.
Tests go above Reliability and Maintainability because the right tests will make the other things easier, if not enable them completely. They also serve as documentation for the nitty-gritty bits that
mightwill get missed/forgotten. Numeric coverage isn't, but valuable coverage is.I'm hesitant to put accessibility so low but, in the same breath as putting functionality so high, if it's difficult to do anything above it then it's difficult to make it more accessible. "ALL users" is a lot of users, but it's presenting what you have in a better way rather than restructuring the fundamentals to make them more accessible.