When thinking about quality, I tend to draw from the following quality attributes:
- Availability
- Buildability
- Conceptual Integrity
- Evolvability
- Extensibility
- Functionality
- Implementation Transparency
- Integrability
- Interoperability
- Maintainability
- Performance
- Portability
- Reliability
- Reusability
- Scalability
- Security
- Serviceability
- Subsetability
- Supportability
- Testability
- Usability
App Types, Verticals, and Scenarios
These qualities–criteria, really–are applicable at every level where we desire quality (and are how we can define and measure quality).
As an example, when I work with dev teams I get them in a room and start a list like this on the whiteboard, asking each developer what 2 or 3 things they most value in their code, in a design, etc. I do the usual NLP hierarchy or criteria process (“what would be so important that it caused you to choose a less-reliable solution over a more-reliable one?” etc.) if I need to elicit more.
Then, I have the tech lead(s) define the shared team hierarchy. The top 5+-2 get put up on the wall in the dev pit, included in emails about code, and are written on the whiteboard at every code review.
“I think this is better” is great to hear (and encouraged); “this supports a higher criteria for this project” is a) behavioral as opposed to personal, b) cuts down on philosophizing when it’s not appropriate, c) teaches more-junior developers not only what to prefer and why to prefer it, but what process to use to make that decision, and d) gets the team using *shared* criteria.
Teams with shared criteria are routinely more successful, have better cohesion, have a lower “bus number”, and produce fewer surprises for S&M, support, and customers. It’s also nice that explicit criteria like these, whether for QA of the product or making decisions in the implementation, helps people keep their personal preference for criteria separate from the project’s preference and still be committed to the project. (i.e., it helps avoid the “I can write LISP in any language!” and “I can shave a couple of clock cycles off this once-a-week process, no matter how many tricks I need to use!” syndromes, plus it makes it easier to address as behavior rather than intention).
In all cases, of course, criteria are heterarchies rather than hierarchies. That’s where the artistry of the more senior engineers comes in. And sometimes the politics between stakeholders 🙂
Great list!
Great rundown and details Seth!
I like your focus on shared values and your approach to team mentoring. I really like your distinction between personal preferences and project preferences.