6 ms·

Let's stop talking about quality

52 points by samstokes 11y ago

leonatan 11y ago
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 11y ago
  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.
  - falsedan 11y ago
    > 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.
  - nidx 11y ago
    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.
zenogais 11y ago
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 11y ago
  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"...
  - Terr_ 11y ago
    > 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."
protomyth 11y ago
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 11y ago
  What _is_ quality, then? I've never heard an objective definition regarding software.
  - protomyth 11y ago
    from the dictionary: ===== 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.
  - lhnz 11y ago
    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.)
cjcenizal 11y ago
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-technical-disagreements-5862a15068fe#.dgudkjr3y https://medium.com/@cjcenizal/seven-strategies-for-resolving....
- deleted 11y ago
  [deleted]
- humanrebar 11y ago
  > 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.
mixmastamyk 11y ago
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 11y ago
  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).
pshc 11y ago
In short: Be specific.
- alexashka 11y ago
  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.
joslin01 11y ago
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 11y ago
  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 11y ago
    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.
  - joslin01 11y ago
    Same here. I was fortunate to read it when I was young & impressionable (~16). It left a profound effect on me that's hard to succinctly express.
trjordan 11y ago
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.
johnrob 11y ago
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.
Lanari 11y ago
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.
ninjakeyboard 11y ago
I found I had an allergic reaction to the title of the article but I agree with its premise.
dhogan 11y ago
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-four-absolutes-of-quality.html http://lansingbusinessnews.com/management-matters/468-the-fo...
batmansmk 11y ago
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 ...").
AndrewUnmuted 11y ago
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.
cushychicken 11y ago
>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

52 points by samstokes 11y ago

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 11y ago
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.
- falsedan 11y ago
  > 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.
- nidx 11y ago
  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.

zenogais 11y ago

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 11y ago
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"...
- Terr_ 11y ago
  > 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."

protomyth 11y ago

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 11y ago
What _is_ quality, then? I've never heard an objective definition regarding software.
- protomyth 11y ago
  from the dictionary: ===== 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.
- lhnz 11y ago
  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.)

cjcenizal 11y ago

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-technical-disagreements-5862a15068fe#.dgudkjr3y https://medium.com/@cjcenizal/seven-strategies-for-resolving....

deleted 11y ago
[deleted]
humanrebar 11y ago
> 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.

mixmastamyk 11y ago

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 11y ago
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).

pshc 11y ago

In short: Be specific.

alexashka 11y ago
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.

joslin01 11y ago

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 11y ago
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 11y ago
  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.
- joslin01 11y ago
  Same here. I was fortunate to read it when I was young & impressionable (~16). It left a profound effect on me that's hard to succinctly express.

trjordan 11y ago

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.

johnrob 11y ago

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.

Lanari 11y ago

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.

ninjakeyboard 11y ago

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

dhogan 11y ago

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-four-absolutes-of-quality.html http://lansingbusinessnews.com/management-matters/468-the-fo...

batmansmk 11y ago

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

AndrewUnmuted 11y ago

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.

cushychicken 11y ago

>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