How can we evolve you today?


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:

Appropriate:   doing the right job (what the stakeholders need)
Correct:   doing the job right (i.e., correctly)
Robust:   hard to make it malfunction, or even seem to
Usable:   easy for the intended users to use
Maintainable:   easy for the developers to change
Efficient:   easy on resources (technical and other)

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:

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:

Appropriate  =>  Applicable
Correct  =>  Correct
Robust  =>  Resilient
Usable  =>  Left out, or maybe part of Applicable
Maintainable  =>  Evolvable and Reasonable
Efficient  =>  Efficient

or to go the other way,

Correct  =>  Correct
Applicable  =>  Appropriate, and maybe Usable
Resilient  =>  Robust
Efficient  =>  Efficient
Evolvable  =>  Part of Maintainable
Reasonable  =>  Part of Maintainable

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:

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:

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.  ;-)