Comment by cushychicken
1 day ago
I think I’ve finally figured out just what is that annoys me about the “software quality” crowd.
Quality is a measurement. That’s how it works in hardware land, anyway. Product defects - and, crucially, their associated cost to the company - are quantified
Quality is not some abstract, feel good concept like “developer experience”. It’s a real, hard number of how much money the company loses to product defects.
Almost every professional software developer I’ve ever met is completely and vehemently opposed to any part of their workflow being quantified. It’s dismissed as “micromanagement” and “bean counting”.
Bruh. You can’t talk about quality with any seriousness while simultaneously refusing metrics. Those two points are antithetical to one another.
Some thoughts regarding this:
1. It is partly because the typical metrics used for software development in big corporations (e.g., test coverage, cyclomatic complexity, etc) are such a snake oil. They are constantly misused and/or misinterpreted by management and because of that cause developers a lot of frustration.
2. Some developers see their craft as a form of art, or at least an activity for "expressing themselves" in an almost literary way. You can laugh at this, but I think it is a very humane way of thinking. We want to feel a deeper meaning and purpose in what we do. Antirez of redis fame have expressed something like this. [0]
3. Many of these programmers are working with games and graphics and they have a very distinct metric: FPS.
[0] https://blog.brachiosoft.com/en/posts/redis/
1. Totally agree that the field of software metrics is dominated by clueless or outright bad actors. I can say with complete certainty that I do not know the right way to measure software quality. All I know is that quality is handled as a metric in most hardware companies, not an abstract concept. When it’s talked about as such an ephemeral thing by software people, it strikes me as a bit disconnected to reality. (If I was going to try, I’d probably shoot for bugs per release version, or time from first spec to feature release.)
2. With respect: that’s a bit of an exceptionalist mindset. There’s nothing precious about software’s value to a business. It’s a vehicle to make money. That’s not to say craft isn’t important - it is, and it has tangible impacts to work. The point I’m making is that: my boss would laugh me out of the room if I told him “You can’t measure the quality of my electronics designs or my delivery process; it’s art.”
3. I’ve never heard of FPS but I’m very interested in learning more. Thanks for sharing the link.
Edit: oh ok duh yeah of course you could measure the frame rate of your graphics stack and get a metric for code quality. D’oh. Whoops. XD
> The point I’m making is that: my boss would laugh me out of the room if I told him “You can’t measure the quality of my electronics designs or my delivery process; it’s art.”
You can find some kind of objective metric, e.g. bug count or time spent developing new features. That alone is super hard to get right, but even if you could, it wouldn't necessarily tell you which techniques lead to a better result. People have tried studying such things (e.g. do static types help) and the studies rarely come up with any effect.
I don't think that's necessarily because these things don't have an individual effect, but because there are humans involved and so, personal ways of thinking probably play an outsized role, so technique X might be a very good fit for person A, but not for person B.
>Quality is a measurement
No it isn't, as in it literally isn't. Quantification is the process of judging something numerically, objectively and in measurement. Qualification is just the opposite, judging something by its nature, essence or kind.
Software quality, like all kinds of quality, is always a subjective and experiential feature. Just like, when someone says, this piece of furniture is a high quality, handmade chair, in all likelihood they haven't performed a numerical analysis of the properties of the chair, they're expressing a subjective, direct sentiment.
The handmade movement in software, was exactly about this, putting focus on the personal, lived judgement of experienced practitioners as opposed to trying to quantify software by some objective metric, that's why individual people feature so heavily in it.
> No it isn't, as in it literally isn't.
Yes, it is. It is a well known field in hardware development, and generally treated as a sub field of manufacturing engineering. It deals with things like testing, sampling, statistics of yield, and process improvement. If you’ve ever done a DFMEA, an 8D report, a Five Whys review, a sampling quality analysis, or a process map, you’ve used tools produced by this discipline.
That’s what I’m trying to tell you and everyone else reading this.
Software, as a profession, collectively talks about quality with all of the rigor of joint passing English majors sharing their favorite sections of Zen and the Art of Motorcycle Maintenance.
Quality has a meaning and a definition and a field of study attached to it. Semiconductors and large scale consumer product manufacturing wouldn’t exist as we know it without this.
> Software, as a profession, collectively talks about quality with all of the rigor of joint passing English majors sharing their favorite sections of Zen and the Art of Motorcycle Maintenance.
Yet people throw around the term "engineers" with reckless abandon for seemingly anyone that wrote Javascript once in their lives. It all strikes me as very silly.
1 reply →
>Quality has a meaning and a definition and a field of study attached to it
Yes and I gave you that definition in the first part of my response. That someone in the semiconductor industry made a poor and colloquial choice of words when he confused qualitative and quantitative processes, (the hardware industry deals with the latter), is not evidence to the contrary.
When people talk about software, they're using the terms appropriately. We can objectively talk about the quantities attached to a software. Number of dependencies, size, startup time, what have you, but two people will never necessarily agree on the quality of software, your high quality software might be junk to me, because that is at its root a subjective judgement. There is not a lot of qualitative or subjective judgement in the world of elementary hardware (it either works or doesn't), there is a lot of it in end user software.
It is very difficult to make a bad piece of hardware that does very well on a number of metrics, it's very easy to make a shoddy piece of software that performs well on an infinite number of metrics, because nobody has a subjective experience with a transistor but they do with a piece of software. That is why you should use the terms correctly and not apply processes from one domain to the other.
1 reply →
I notice you have not quantified any aspect of your opinion, here. Which is not surprising, since your opinion is unrelated to facts, science, experience, or wisdom.
Quality is not a "real, hard number" because such a thing would depend entirely on how you collect the data, what you count as data, and how you interpret the data. All of this is brimming with controversy, as you might know if you had read more than zero books about qualitative research, epistemology, the philosophy, history, or practice of science. I say "might" because of course, the number of books one reads is no measure of wisdom. It is one indicator of an interest to learn, though.
It would be nice if you had learned, in your years on Earth, that you can't talk about quality with any seriousness while simultaneously refusing to accept that quality is about people, relationships, and feelings. It's about risks and interpretations of risk.
Now, here is the part where I agree with you: quality is assessed, not measured. But that assessment is based on evidence, and one kind of evidence is stuff that can be usefully measured.
While there is no such thing as a "qualitometer," we should not be automatically opposed to measuring things that may help us and not hurt us.
I’m not sure what conclusion to draw from this comment, apart from the fact that you’ve sure made a lot of assumptions about me and my experience.
For a guy who just made a uniformly damning and unnuanced statement about his peers in the industry, your concerns about "making a lot of assumptions" ring rather hollow. Perhaps you think only other people have to lay out their evidence and argument in a rigorous way, but not you?
Anyway, you could analyze my comment and reply. That's what I did with yours. Perhaps you could call my apparent bluff and challenge what I claim to know about epistemology. Maybe you're having trouble doing that because analysis wasn't how you arrived at your own opinion? You were expressing an ideological position that you inherited from-- I'm just guessing-- one article about Six Sigma or TQM that was 30 years old?
I read Quality Without Tears, by Phil Crosby, in 1987, that expressed much the same attitude as you just did. I've had a lot of time, since then, to become educated and experienced in these things.