
Let's stop talking about quality - samstokes
http://blog.samstokes.co.uk/blog/2016/02/24/quality-vs-empathy/
======
joslin01
Some quotes from a guy who went mad thinking about quality. In short, you
don't want to stop talking about quality but learn how to move toward it. And
no, quality is not a boolean value nor does it have to create fears of
judgment. These are just effects of striving for idealism.

“Care and Quality are internal and external aspects of the same thing. A
person who sees Quality and feels it as he works is a person who cares. A
person who cares about what he sees and does is a person who’s bound to have
some characteristic of quality.”

― Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance: An Inquiry Into
Values

“You’ve got to live right, too. It’s the way you live that predisposes you to
avoid the traps and see the right facts. You want to know how to paint a
perfect painting? It’s easy. Make yourself perfect and then just paint
naturally. That’s the way all the experts do it. The making of a painting or
the fixing of a motorcycle isn’t separate from the rest of your existence. If
you’re a sloppy thinker the six days of the week you aren’t working on your
machine, what trap avoidance, what gimmicks, can make you all of a sudden
sharp on the seventh? It all goes together ... The real cycle you're working
in is a cycle called yourself. The machine that appears to be "out there" and
the person that appears to be "in here" are not two separate things. They grow
toward Quality or fall away from Quality together.”

― Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance: An Inquiry Into
Values

~~~
mikeyouse
Exactly what I thought of as well.. I know it's cliche but Zen really helped
me clarify my thoughts on quality and the different ways to pursue it.

~~~
hencq
I went to the comments to mention Zen and was glad it was already the top
comment. I was lucky enough to get introduced to it early in college as it
really got me thinking about quality. I should probably re-read it again to
see if my thinking evolved since.

------
trjordan
I agree with a lot of this article, but I think it underestimates how much
time it takes to properly prioritize good software practices against the
business needs. There's the trivial case (the DB is down, nobody can log in)
where they're aligned, but there's a lot of other work where it's not obvious
what's the most important thing to the business.

This is why PMs have jobs. For every deep, hard-to-understand drag on feature
velocity based on technical debt, there's a deal that's going to make the
renewals team miss the quarter because of a missing feature deadline.
Balancing those against each other is apples to oranges, so it's impossible to
make everybody feel great about that.

A friend recently suggested that the way to do this is pre-arrange a schedule
for "quality". Dedicate 30% of dev time to maintenance / debt / refactoring /
whatever you want to call it, then stick to that. I think this is a more
pragmatic way to approach it, because otherwise you're asking every engineer
to understand the whole of the business at every Scrum meeting. Not only is
that intractable, I know plenty of engineers who don't want to think about the
plight of sales / marketing / renewals. Let the PM do their job prioritizing
features for them, and let the engineering team prioritize and work on
quality.

------
zenogais
I got kinda lost right out the gate - mostly because quality can be used in an
objective fashion as something that is measured and managed. Though not in
most small software organizations. For example, in my work we measure
percentage of team time spent fixing defects (bugs), new defect tickets per
week, etc. In my personal work I usually measure Defects per KLOC during
development and number of defects found after completion. All of these
measures allow for objective conversations about quality - "that big crunch we
did to finish last week, while it resulted in 25% more defect tickets opened
this week, most of them related to the newly released work".

I appreciate this perspective and I'm all for communication and empathy, but I
think the belief that quality is hopelessly subjective is misguided.
Additionally, the belief that all differences are reconcilable, while nice, is
simply untrue. I have yet to work in an organization that didn't have multiple
and competing tensions between individuals with different goals. This is fine,
and learning to compromise is important, but also accepting that some
differences just can't be bridged and learning to work as a team anyway is
just as important.

~~~
jrs235
What “we don’t have time for quality” really means is: “I’m not sure what you
mean by quality, ..."

Your definition of quality doesn't address the Marketing/UI persons definition
of quality pertaining to the quality of the UI. Quality can be objective and
quantitative when it is bounded within a certain context. Too often, quality
is used by different people to mean different things because we haven't
bounded it. this is why communication is key to understanding what someone
means when THEY are talking about quality.

EDIT: To add to this... let's stop talking about "Quality" let's talk about
"Defects per KLOC" and "User engagement" and "Clicks to do"...

~~~
marcosdumay
Your metrics don't touch software plasticity (capacity to receive changes) at
all, yet it is one of the most important components of software quality.

~~~
jrs235
Correct. The ones I randomly picked don't cover plasticity. How does one
measure (and convey) software plasticity to other [non-technical]
shareholders?

Tech: "It's going to take x amount of time to refactor so that the software
can easily change in the future" BusDev: "What if we don't need it to change
[like that] in the future?"

How does Tech and BusDev objectively measure the software plasticity if it
can't be measured until change must occur? "Our software is X plastic" means
what? "This change will take 1 day instead of a 1 week because we made our
software plastic." What if you pre-optimzied plasticity and YAGNI'ed wasting
precious time and resources. This is where things get real dicey... trying to
objectively measure the importance and value of clean code. WE, techs,
understand it and can feel it while trying to implement new features and
changes but those that don't touch or understand code can't.

ADD: How do we determine the code is clean (and refactored) enough (but not
too much)? "Everything should be made as simple as possible, but not simpler."
"Do as much is needed but nothing more"?

~~~
marcosdumay
I have no idea how to convey plasticity to shareholders. I think it's the
hardest quality to measure, and that's why I pointed it.

The GP and, for a lesser extent (but it's cumulative) you are talking about
easy to measure, and yes, important metrics. But those are not the only ones.
There are also hard to measure components of quality that do make it more
subjective.

------
cjcenizal
I think the author hits on an important point under the "Common Ground"
section: discussions should be collaborative, not argumentative. If you're
trying to make a decision with a "me vs. you" mindset, the decision won't get
made. Instead, try to frame it as an "us vs. the problem" situation, which
helps everyone contribute and work multiple angles to find the best solution,
keeping multiple considerations in mind -- including code "quality".

If anyone's interested in more on this, I wrote a short Medium post on other
strategies for making better technical decisions:
[https://medium.com/@cjcenizal/seven-strategies-for-
resolving...](https://medium.com/@cjcenizal/seven-strategies-for-resolving-
technical-disagreements-5862a15068fe#.dgudkjr3y).

~~~
humanrebar
> discussions should be collaborative, not argumentative

There's a bit of a prisoner's dilemma here, though. I've tried the
collaborative approach with decision makers before only to get grilled, spun
into a defensive position, and ultimately dismissed.

I think, generally, developers are empathetic to business needs, though they
may disagree about the specifics. I find the lack of collaboration comes from
the other side of things. Often because of a lack of context from the business
side.

------
Lanari
The first rule on the tech startups field is to not make "quality products",
simply because you can't afford it. Then to claim you are making "quality
products" because you can't afford not saying it.

I was stuck with "making perfect projects" for long and got no profit from it,
now I do both, I work simultaneously (I'm a NEET so a lot of time in hand) on
one "perfect" with vanilla code and the other with a framework and any library
I see online. The result is I finish several "non-perfect" projects and the
one I'm working on almost finished and took me 2 months, the "perfect" project
is taking me 3 years so far.

It's a balance for me between joy and the need of money, and from my
experience if you want to make some money just forget the "making quality
products" BS and deal with it as a meme, Ayy LMAO.

------
leonatan
I don't agree with the article. Empathy, communication and quality are not
mutually exclusive. I can empathize and sympathize with the strains of
timelines, deadlines and crazy demands, but that does not mean we developers
and users should not push or demand quality software. This type of attitude
is, in my opinion, why software quality has been going downhill over recent
years. Start ups looking for the quickest buck, corporations ignoring user
experience to appease crazy administrator demands. Quality should be the most
talked about when it comes to software. It's not binary; it's an umbrella term
to express satisfaction; it can be broken to many subcategories, true, but
still can be used to express overall impression.

~~~
wambotron
You can't really define what quality software is, though. You could have a
patched together backend that "just works" and has a great UI that customers
love, but how is that "quality" software? The software end of it is clunky and
patched.

On the other hand, you can have completely documented, easy to read, well
thought-out code that has a terrible UI that no one will bother using. I guess
you can say the software is "quality," but it doesn't matter.

Then again, maybe "quality" software to you is software that works, like the
first example. In that case, it doesn't matter how well documented it is. It
works. It's self-readable at least to those who wrote it. Maybe the team will
never grow beyond that, so who cares? Or by the time it does, it will be
rewritten anyway for other reasons.

The point, I think, the author is trying to make is that quality means so many
things it means nothing. It's a useless term because it has no objective
meaning. We can argue about what you think quality is and what I think it is,
but it's likely going to be different for any two people.

~~~
nidx
Quality software is pretty easy to define and you described it.

Quality software is software that works for _everyone_ who uses it. That is
usually a very long list

    
    
      - users
      - developers
      - new developers
      - testers/qa
      - designers
      - admins
      - managers
      - sales people
      - third party integration
      - apis
      - etc.
    

You are right that most of this comes down to the iceberg problem (you only
see the issues you focus on but there are many more hidden to you)

The author is very foolishly thinking that communication is possible in their
"solution" I can have speeches for hours with managers and sales people and
have them still completely ignore quality.

------
batmansmk
Try working on an automated car, space shuttle, encryption algorithm, robot,
medical equipment, security systems, ... I'm happy the engineers working on
those ones don't have the same perspective as our dear Sam.

I think this point of view has to be limited to a really Silicon Valley /
consumer products experience: "we will add a button in an app that will be
ground-breaking!" The opposition of the two models of discussion shouldn't
exist, as quality is indeed a business decision ("do you need a software with
less defects? Or you are okay paying for more support and the risk of loosing
users and image and ...").

------
dhogan
I think this comes about when there is no good definition of quality. If you
say quality is "conformance to requirements," you have a starting place. Then
measurement can be seen as the price of nonconformance. Check it:
[http://lansingbusinessnews.com/management-matters/468-the-
fo...](http://lansingbusinessnews.com/management-matters/468-the-four-
absolutes-of-quality.html)

------
mixmastamyk
This is kind of an odd article, didn't completely know what to make of it.
There is another definition to the word quality, probably the original, which
means "property". For example, color, texture, and density are qualities of an
object.

As such the QA dept reports on the current status of a project in several
dimensions, not that it has met a binary threshold of excellence.

~~~
6stringmerc
Same, as I saw it start in one direction (objection to a term) and then move
toward a different one (larger discussion of communication and format?) in
order to work through...I guess the issue with the term quality at the outset?
There's some crossing between 'quality' and 'goals' that doesn't quite make
sense to me, because logically I tend to think there's an "objective"
perspective to whether goals have been reached or not in a fashion that
reflects...quality...Not necessarily in the 'property' definition, but
definitely related, in that achieving the goal would be reliant on the quality
of the work in both views (e.g. it has the property of working and it works
properly).

------
AndrewUnmuted
I really vibed with this article.

For my entire career, I've attempted to make the distinction between _quality_
and _fidelity_.

Quality, as the article suggests, is a subjective term that is determined via
individual experience.

Fidelity, on the other hand, is the concept of making something which adheres
to the requirements/specifications/best practices of the realm in which the
thing exists.

So much of the technology business has failed not because of bad ideas but
because of bad communication of those ideas. As technology becomes more and
more ubiquitous within the lives of creative individuals, the need to
understand this duality will be even greater.

------
johnrob
Paul Graham actually has a blueprint for managing these kind of tradeoffs
(speed vs quality) in his growth essay:
[http://paulgraham.com/growth.html](http://paulgraham.com/growth.html). While
the main point is that growth defines startups, there's another point
(possibly more impactful) that claims hitting your growth goals is the best
decision making device.

------
cushychicken
>Instead of talking about quality, let’s talk about goals. We want to see
whether customers engage with this new feature. We want to cut down how often
our engineers get paged at 3am. We want the main features to be at most 3
clicks away. We want to communicate the value of the product in the first 5
minutes. Let’s talk about how our different goals interact. Maybe there’s a
way to do it that gets everyone closer to their goals?

Quality, in engineering terms, boils down to setting standards for your work,
and then meeting them. You could argue the converse of everything in this
article is true, or actually a good thing; in a way, Paul Graham's essay on
taste does [1]. There has to be some system for evaluating work as "good"
versus "not good". It's effectively writing specs for company operation.

It sounds like the author has been a victim of either vague standards or poor
prioritization. It's pretty clear how either scenario would thoroughly suck to
work for.

[1][http://www.paulgraham.com/taste.html](http://www.paulgraham.com/taste.html)

------
protomyth
This really seems like a redefining of what the word Quality means to make
some other point. "Quality is subjective" is a pretty poor statement since
quality has a pretty objective definition.

~~~
wambotron
What _is_ quality, then? I've never heard an objective definition regarding
software.

~~~
lhnz
Quality is something you qualify, quantify (measure) and optimise for.

For example, consider a team that wanted to hire people that they considered
'Empathetic'. Firstly they would need to define what they consider good
signals of this, secondly they would need to share some kind of system of
measure of it, and then finally they'd be able to optimise for it by trying to
create the context and behaviour that they believe would increase its
likelihood (e.g. hiring people that went to a lot of Empathy training days at
their previous companies).

My point is that the definition of quality is objective but abstract. In
practice it refers to a concrete property that you wish to optimise for, and
this choice of how and what to measure as quality is a subjective decision
requiring coordination.

That does not mean it's not a useful concept, and that therefore everything
should be considered equal. Most people prefer to act with regard to their
preferences, and that is why people often talk about something called quality
even though it's difficult to pin-down.

(This is conceptually similar to Merit which is another abstract word people
use to help coordinate human activity.)

~~~
abakker
The objective definition is very difficult to pin down. My personal takeaway
is that quality in practical day to day life is a trait which lets us judge
things comparatively, not objectively.

Thats an important distinction though. While it is difficult pin down whether
something individual _is quality_ or _has quality_ , it is easy enough to
compare it to something else and say whether it has more or less.

When most people say "this is a quality _______", the comparison is implicit.

~~~
lhnz
What I mean is that the objective definition of Quality is abstract and not
very hard to pin down. However the way that people use it is to refer to
concrete 'qualities' that groups of people coordinate around measuring and
_these are subjective, hard to pin down, but often useful_.

I agree with you that a common property of a 'quality' is that it can be
compared (without this property it would not be measurable.)

When people say "this is a quality _______", I think it's useful to ask them
why that is Good, and what properties it had that helped them realise it was
'quality'.

Plain disagreement about the usefulness of the concept of measuring and
optimising for certain properties annoys me, because often the people that do
this are just trying to replace the original system with one of their own.

------
pshc
In short: Be specific.

~~~
alexashka
Yup.

Quality is about doing just enough of what's necessary and as little of what's
unnecessary as possible.

If I asked the author to make the same points in 20% the time and remove
unnecessary images, his/her article would be of higher quality.

See, if someone can't identify what makes an article high quality or doesn't
care to make it that before posting it online - I question whether that person
is well suited to speak on quality in the first place.

------
ninjakeyboard
I found I had an allergic reaction to the title of the article but I agree
with its premise.

