That's super catchy, I've used it myself when arguing against late-in-the-cycle requirements additions, but...
"Quality" isn't something you can define readily. http://en.wikipedia.org/wiki/Software_quality lists 20 things, some mutually contradictory, that often are considered aspects of "quality" software.
I've become cynical about it. I know what I mean: software that never crashes, and runs rapidly. I don't know that managers, directors, senior directors, vice presidents, etc of development mean. I believe that vendors use the word 'quality" a lot when trying to get senior directors and VPs to buy into "enterprise software", like SharePoint or "Smart Filter" browser nannies, or any proprietary version control system that imposes a "lifecycle" on development. The vendors use "quality" because they know "quality" means a bunch of different things, and that Senior Directors and VPs never realize that "strict compliance with PCI" might not be the same "quality" that the developers think of, and it certainly isn't what the users think of.
> I know what I mean: software that never crashes, and runs rapidly.
stability and efficiency shouldn't be the only factors you focus on. An empty loop is pretty fast and stable, but wouldn't solve most of the problems you're expected to solve. It sounds like you're just taking all the other factors for granted, where in reality they're as hard or harder to get right as stability and efficiency.
Actually, I was just trying to point out that the word "quality" means different things to people. I was only giving a rather flip example. As you point out, my definition has a trivial degenerate case. But if I want to make a point about vendors peddling "enterprise" software relying on Vice President's defining "quality" differently than a developer would, I need that snappy counterexample.
3 comments
[ 3.2 ms ] story [ 19.6 ms ] thread"Quality" isn't something you can define readily. http://en.wikipedia.org/wiki/Software_quality lists 20 things, some mutually contradictory, that often are considered aspects of "quality" software.
I've become cynical about it. I know what I mean: software that never crashes, and runs rapidly. I don't know that managers, directors, senior directors, vice presidents, etc of development mean. I believe that vendors use the word 'quality" a lot when trying to get senior directors and VPs to buy into "enterprise software", like SharePoint or "Smart Filter" browser nannies, or any proprietary version control system that imposes a "lifecycle" on development. The vendors use "quality" because they know "quality" means a bunch of different things, and that Senior Directors and VPs never realize that "strict compliance with PCI" might not be the same "quality" that the developers think of, and it certainly isn't what the users think of.
stability and efficiency shouldn't be the only factors you focus on. An empty loop is pretty fast and stable, but wouldn't solve most of the problems you're expected to solve. It sounds like you're just taking all the other factors for granted, where in reality they're as hard or harder to get right as stability and efficiency.