🦖

Codosaurus 🦖

The ACRUMEN software quality definition is a simple list of briefly-named and easily-understood aspects that more or less completely cover the subject of software quality, to the level that five-nines of us will ever need.  The acronym ACRUMEN (try saying that ten times fast) stands for the idea that software should be:

So what does the N stand for?  Nothing, I just tacked it on to make a real word!  ;-)

And why all this yellow?!  I said “acrumen” was a real word, but I didn’t say it was English!  It’s Latin for sour fruit, such as grapefruit, limes, and of course especially lemons.  So, lemon yellow is the official color of ACRUMEN.

So why do we need another definition?  Most of the ones I found, when I was looking for one several years ago, have one or more serious problems:

• Many are long lists of abstruse terms, so they’re nearly impossible to remember (never mind teach to juniors) and very difficult to apply.

• Many are proprietary, so we need to buy expensive software tools, and/or expensive documents.  (Yeah, I’m lookin’ straight at you, ITU!  And don’t think I don’t see you sneakin’ around there, ISO!)

• Many are only applicable to certain kinds of software, such as Object-Oriented programming or a web application.

• Many are more focused on the process or some byproducts, saying you must hold some particular meetings or write some particular documents.  Those things might be useful, but to make them part of the definition entirely misses the point.  It’s certainly possibly to hold the meetings and produce the documents yet produce low-quality software, or produce high-quality software without them.

But I did find some good things.  In particular, Phil Nash’s “CAREER” system is very good . . . and almost the same as ACRUMEN.  (That’s how I know it’s good, he said ever so humbly.)  You can get some explanation from this YouTube video of his presentation to the Munich C++ Meetup, including some interesting exploration of the interplay between some pairs of aspects.  To compare and contrast a bit:

or to go the other way,

I still prefer ACRUMEN because it prioritizes the aspects (at least for the typical case), and doesn’t repeat any letters.  :-)

Unfortunately I didn’t discover CAREER until I had been working/writing on ACRUMEN for several years.  Oh well.  Maybe we can work on unifying our ideas.  We’ve already been discussing our systems.

Stu Crock has an interesting definition, that’s even briefer:

Quality is the absence of unnecessary friction.

As I told him on Twitter in July 2022, it’s “[n]ot immediately actionable, but the freeform explorations necessary to get there, could lead to some great insights.”  In other words, it’s a great prompt for some very productive thinking.  What he does with it, is to identify types of friction present in the system, then see which ones are necessary or not in the given situation.  Often he will ask stakeholders to identify particular areas to focus on, which can help guide and prioritize his investigation into sources and types of friction.

In 2021, Margaret-Anne Storey, Brian Houck, and Thomas Zimmermann wrote a paper on “How Developers and Managers Define and Trade Productivity for Quality”.  It included some fascinating insights into what each group thought the other would say, but more relevantly, also ways to boil both of those ideas down to a short list of aspects!  What they wound up for for quality was a set forming the acronym TRUCE:

• Timeliness of features delivered
• Robustness of features
• User delight
• Collaboration needs (of the developers) met
• Evolution needs (of the developers) met

While I can’t fault their methodology, it was pretty clear to me that they were aiming for something quite a bit different, and thus wound up with aspects that were mostly not well suited for the kind of definition I was after.  The Collaboration and Evolution needs of the developers could possibly be counted among the “stakeholder needs” that software needs to meet in order to be Appropriate, though that’s in the past once the software is released.  User Delight could be considered part of Usability.  We both had the idea of Robustness.  However, only the Robustness and User Delight would be at all visible to end users, or almost anyone other than the dev team.  I emailed Dr. Storey about it, and she confirmed that they were looking at it mainly from the point of view of the developers and their management.  So, while we’re not at all on the same page, that seems to be because she and Brian and Tom are reading a different book — still a good one, but different.

For further explanation, see these blog posts:

• ACRUMEN
• ACRUMEN: Appropriateness
• ACRUMEN: Correctness
• ACRUMEN: Robustness
• ACRUMEN: Usability
• ACRUMEN: Maintainability
• ACRUMEN: Efficiency

More explanation of ACRUMEN might be coming here eventually.  For now, see my ACRUMEN YouTube playlist.

Or of course you can have me conduct a training class at your company.  ;-)