“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
I have a lot of discussions at work that end with something like "we all agree that X would be the quality/elegant/long-term solution, but we don't have time to do X right now, so we'll do the hacky solution Y until we have time to implement X." These are good decisions! The immediate problem gets solved fast, and we've identified a really good elegant solution and given ourselves enough time to implement it.
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.
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"...
Unfortunately most of those metrics lead to paperclip-maximizing. In particular, I'm fighting the "clicks to do" metric being used by a certain stakeholder.
"With your design, every user will need training and rote-memorization to know which clicks to make, they'll never really know why it works or how to recover when things are different, they'll spend 10 seconds waiting for each bloated page to load, and another 3 seconds scanning for the button-shape that they learned..."
"...But yes, I suppose it reduces the minimum-clicks-needed from five to three. Technically."
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.
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.
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.
> 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.
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.)
=====
the standard of something as measured against other things of a similar kind; the degree of excellence of something: an improvement in product quality | the hospital ranks in the top tier in quality of care.
general excellence of standard or level: a masterpiece for connoisseurs of quality | [ as modifier ] : a wide choice of quality beers.
=====
Seems pretty simple applied to software. Intuitively does what it says it does in a bug free manner.
If you want to get into a discussion that parallels why people call modern art great and there can be no standards for what is art, then I'm really not interested. I don't believe a white canvas is art, and I believe software and art can have objective standards.
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....
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.
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.
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.
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.
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.
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 ...").
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.
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.