Better/Sooner/Cheaper/More—I began talking this week about a fundamental Extreme Programming technique for managing resources & immediately remembered why I stopped talking about it.
Would you then perceive "better" as "more maintainable"? - when talking traditional software 'qualities' that has always been what I've been arguing for when arguing for quality. One might be a subset of the other. or is it something else?
Interesting article, but I tend to agree with Ted Husted. "Better" depends on the perspective. Here is a recent example:
1. Initial task: allow admins to change a user's role from the UI
2. Implemented as requested
3. Then the client says "It would be better to notify the server administrator when a user role is changed"
So ... a confusion appears between better and scope.
- from the client's perspective it is "better" as in a more correct implementation of the original requirements, even though it was not originally specified
- from my perspective as the programmer is "expanding the scope" as in adding new things that were not requested originally
I believe the word "better" is too vague and too contextual and means different things to different people in different mind sets.
I'm glad we're having this conversation. This isn't about the "right" words, this is about what vocabulary will be effective at:
1) informing everyone's intuition
2) encouraging productive conversations, especially in the presence of conflict.
I think "quality" is not a word that advances either purpose. I like "better" because it implies a choice--we can work to make it better or not. I like "better" because it flushes out the "for whom" conversation that so often is buried beneath layers of power. And I like "better" because my bias is to lean towards better (since we've been leaning towards worse for so many decades), and "better" sounds attractive.
I think what needs to be clarified here is exactly that "better for whom?". As the blog post is today, every reader will interpret "better" from their point of view. I am a long time software developer and power user of all software I use.
If I read this article with a developer eye, what I did at first read, "better" means cleaner code/design/architecture. So, "better" refers to implementation.
If I read this article with a power user eye, what I do now, "better" means more and easier to use features for application X. So, "better" refers to usage.
And these are two "betters" that may or may not conflict. What is "better" to the developer does not imply "better" to the user and vice versa.
Thinking about it, probably this was the background thought in the first place that made me comment on this article.
In my view, quality is a value or a state as it is. Better, in my opinion, lays in the field of "perceived value". And that depends on the eye of the beholder and is prone to opinion.
For example, a tool can be made out of vanadium enforced steel, properly constructed, maybe even handmade etc. In a sense, it's of the finest quality. Nobody can deny it. But, is it functional and easily usable? Do you need help to use it or can it maybe even operate on its own without attendance?
Thus, there are more properties that distinguish if something is of good or even excellent quality and properties that make it usable, intuitive or maybe even easier.
Code can be tidy, properly adhering to best practices etc. and all kinds of properties that makes it of good quality. But if it is awful to use or apply or access it is out of the field of perceived value to many a customer.
In other words: how it's made does not equal to how it's being used or applied. Improved or of higher quality are not the same thing.
Sponsors of software projects often feel out of control. That's because they *are* out of control, but it leads them to act harmfully to their own (and everyone else's) interests (except maybe competitors). The model gives them something useful to do--help cut scope & encourage quality. That's why "better" is there.
Thank you for the question, though. I think there is still something missing from my presentation. I'll keep experimenting.
There are more communities involved than that. And there are feedback loops--better for customer that becomes worse for the programmers then becomes worse for the customer. (Substitute various other communities.)
I feel like "better" is being conflated to mean either "quality" or "scope" depending on the context.
Should we be using the terms from the PM Iron Triangle? -- https://www.villanovau.com/wp-content/uploads/2021/10/img_Iron-Triangle-Project-Management-1.png
In practice there has always been a clear distinction between better and scope.
Would you then perceive "better" as "more maintainable"? - when talking traditional software 'qualities' that has always been what I've been arguing for when arguing for quality. One might be a subset of the other. or is it something else?
You mention this is the next post! silly me!
Interesting article, but I tend to agree with Ted Husted. "Better" depends on the perspective. Here is a recent example:
1. Initial task: allow admins to change a user's role from the UI
2. Implemented as requested
3. Then the client says "It would be better to notify the server administrator when a user role is changed"
So ... a confusion appears between better and scope.
- from the client's perspective it is "better" as in a more correct implementation of the original requirements, even though it was not originally specified
- from my perspective as the programmer is "expanding the scope" as in adding new things that were not requested originally
I believe the word "better" is too vague and too contextual and means different things to different people in different mind sets.
I'm glad we're having this conversation. This isn't about the "right" words, this is about what vocabulary will be effective at:
1) informing everyone's intuition
2) encouraging productive conversations, especially in the presence of conflict.
I think "quality" is not a word that advances either purpose. I like "better" because it implies a choice--we can work to make it better or not. I like "better" because it flushes out the "for whom" conversation that so often is buried beneath layers of power. And I like "better" because my bias is to lean towards better (since we've been leaning towards worse for so many decades), and "better" sounds attractive.
I think what needs to be clarified here is exactly that "better for whom?". As the blog post is today, every reader will interpret "better" from their point of view. I am a long time software developer and power user of all software I use.
If I read this article with a developer eye, what I did at first read, "better" means cleaner code/design/architecture. So, "better" refers to implementation.
If I read this article with a power user eye, what I do now, "better" means more and easier to use features for application X. So, "better" refers to usage.
And these are two "betters" that may or may not conflict. What is "better" to the developer does not imply "better" to the user and vice versa.
Thinking about it, probably this was the background thought in the first place that made me comment on this article.
In my view, quality is a value or a state as it is. Better, in my opinion, lays in the field of "perceived value". And that depends on the eye of the beholder and is prone to opinion.
For example, a tool can be made out of vanadium enforced steel, properly constructed, maybe even handmade etc. In a sense, it's of the finest quality. Nobody can deny it. But, is it functional and easily usable? Do you need help to use it or can it maybe even operate on its own without attendance?
Thus, there are more properties that distinguish if something is of good or even excellent quality and properties that make it usable, intuitive or maybe even easier.
Code can be tidy, properly adhering to best practices etc. and all kinds of properties that makes it of good quality. But if it is awful to use or apply or access it is out of the field of perceived value to many a customer.
In other words: how it's made does not equal to how it's being used or applied. Improved or of higher quality are not the same thing.
Why even have Better as an option to chose from? It shouldn't be an option. I think overall we cannot afford to make "unBetter" software.
Sponsors of software projects often feel out of control. That's because they *are* out of control, but it leads them to act harmfully to their own (and everyone else's) interests (except maybe competitors). The model gives them something useful to do--help cut scope & encourage quality. That's why "better" is there.
Thank you for the question, though. I think there is still something missing from my presentation. I'll keep experimenting.
Better for the customer. The customer decides.
There are more communities involved than that. And there are feedback loops--better for customer that becomes worse for the programmers then becomes worse for the customer. (Substitute various other communities.)