3 ms·

> I’m a bit despondent over the casual approach to quality exhibited by a lot of corporations, and the stakes are getting higher. I don't think that there is a

by OldHand2018 6y ago

> I’m a bit despondent over the casual approach to quality exhibited by a lot of corporations, and the stakes are getting higher. I don't think that there is any evidence that the quality of the software was low. The problem was the design of the system and the willingness of the developers to implement it.

ChrisMarshallNY 6y ago
Fair 'nuff, but I still have my feelings about it. > The problem was the design of the system and the willingness of the developers to implement it. I would consider the design of the system as a "quality" metric. Usability, accessibility, training and support are all what I consider to be important components of "quality." We have a big problem (not just in our industry) of "Not mah job, man."
- OldHand2018 6y ago
  Using your definition, I'd definitely agree that there is a big problem.
  - ChrisMarshallNY 6y ago
    I have a "holistic" system approach. I believe that every system; whether software, hardware, design, written materials, whatever, needs to be treated as a "whole," and that "whole" often includes components that may not be considered relevant to implementors. Take, for, example, end-user documentation. That's often considered "not mah job, man" by engineers; which is appropriate. It is not their job, –and, this is important– if some knucklehead manager makes it their job, they are gonna get a real turd sandwich for end-user documentation. What needs to happen, is that the manager needs to hire a real tech writer (not a repurposed administrator -unless they get lucky), and then supply that writer with the tools and authority necessary to do a good job. Stop me if you've heard this before. A lot of startups don't have this luxury. Almost every person in the company is wearing half a dozen hats. The CTO may be the main (sometimes, only) engineer. For whatever reason, they don't have headcount money for a tech writer, so the CTO, who is, to be fair, an amazing and energetic engineer, writes the user docs. Unfortunately, she is also intimately familiar with the system, and has a very advanced baseline. She does not approach the documentation with an eye towards new users, coming in hot and two engines shot to hell. She assumes that they are engineers of her caliber, and that they "of course" know the basics that she glosses over. So we have this marvelous system, that was produced by marvelous people, and is presented to the user, wrapped in a turd sandwich.

ChrisMarshallNY 6y ago

Fair 'nuff, but I still have my feelings about it. > The problem was the design of the system and the willingness of the developers to implement it. I would consider the design of the system as a "quality" metric. Usability, accessibility, training and support are all what I consider to be important components of "quality." We have a big problem (not just in our industry) of "Not mah job, man."

OldHand2018 6y ago
Using your definition, I'd definitely agree that there is a big problem.
- ChrisMarshallNY 6y ago
  I have a "holistic" system approach. I believe that every system; whether software, hardware, design, written materials, whatever, needs to be treated as a "whole," and that "whole" often includes components that may not be considered relevant to implementors. Take, for, example, end-user documentation. That's often considered "not mah job, man" by engineers; which is appropriate. It is not their job, –and, this is important– if some knucklehead manager makes it their job, they are gonna get a real turd sandwich for end-user documentation. What needs to happen, is that the manager needs to hire a real tech writer (not a repurposed administrator -unless they get lucky), and then supply that writer with the tools and authority necessary to do a good job. Stop me if you've heard this before. A lot of startups don't have this luxury. Almost every person in the company is wearing half a dozen hats. The CTO may be the main (sometimes, only) engineer. For whatever reason, they don't have headcount money for a tech writer, so the CTO, who is, to be fair, an amazing and energetic engineer, writes the user docs. Unfortunately, she is also intimately familiar with the system, and has a very advanced baseline. She does not approach the documentation with an eye towards new users, coming in hot and two engines shot to hell. She assumes that they are engineers of her caliber, and that they "of course" know the basics that she glosses over. So we have this marvelous system, that was produced by marvelous people, and is presented to the user, wrapped in a turd sandwich.