from Hacker News

Let's stop talking about quality

by samstokes on 2/25/16, 5:06 PM with 37 comments

• by joslin01 on 2/25/16, 5:52 PM

  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

• by trjordan on 2/25/16, 5:55 PM

  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.

• by zenogais on 2/25/16, 5:43 PM

  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.

• by cjcenizal on 2/25/16, 5:48 PM

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

• by Lanari on 2/25/16, 6:23 PM

  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.

• by leonatan on 2/25/16, 5:42 PM

  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.

• by batmansmk on 2/25/16, 6:33 PM

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

• by dhogan on 2/25/16, 6:31 PM

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

• by mixmastamyk on 2/25/16, 5:49 PM

  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.

• by AndrewUnmuted on 2/25/16, 6:49 PM

  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.

• by johnrob on 2/25/16, 6:17 PM

  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.

• by cushychicken on 2/25/16, 7:03 PM

  >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

• by protomyth on 2/25/16, 5:47 PM

  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.

• by pshc on 2/25/16, 5:52 PM

  In short: Be specific.

• by ninjakeyboard on 2/25/16, 6:26 PM

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