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.
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.
> 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.
We've been discussing what quality for our team at work, and one of the key outcomes has been recognising 'Perceived Quality' & 'Actual Quality' as distinct concepts. The main difference is, to a user, they are the same and can't be distinguished--until something goes wrong.
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.
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.
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"...
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"?
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.
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.
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.
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.)
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.
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.
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".
> 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.
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.
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).
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.
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
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.
OPs point is that there is a pattern they see where people use the word quality and make an ultimatum. They would rather see people have a deeper discussion on constraints and generally show more empathy rather than constantly using a one liner that cuts off communication.
I definitely agree that quality doesn't have to be a boolean, and it also doesn't have to be a loaded term like the author seems to believe.
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 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.
Paul Graham actually has a blueprint for managing these kind of tradeoffs (speed vs quality) in his growth essay: 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.
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.
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...
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 ...").
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.
>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.
37 comments
[ 3.3 ms ] story [ 86.1 ms ] threadOn 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
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.
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"...
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"?
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.
=====
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.
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.)
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.
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.
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.
“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.
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.
[1]http://www.paulgraham.com/taste.html