5 ms·

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 s

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

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