6 ms·

That's great when the feature set you're talking about has already been validated by the market. When it's not, it's a mistake to focus on that. I believe we ca

That's great when the feature set you're talking about has already been validated by the market. When it's not, it's a mistake to focus on that. I believe we call that "premature optimization."

ddingus 6y ago
Many will not evaluate software that is unstable, because that is a clear sign the whole effort is not yet suitable for any meaningful time investment. Play it how you will, of course. I will pass hard personally. Lack of stability is very high on my qualification list. To be blunt, where it exists there are other priority problems. One may just be flashy speed and other sizzle done at the general expense of the solution being robust. May only take an event or two needed to cancel out potential gains from those things. Turn that crank a time or two and many will just get back to work. An attempt or two again? Many will ignore the solution and or have adopted something else. Net result? The team that did not make stability a priority likely did a lot of market building for the ones who did.
- cycloptic 6y ago
  >The team that did not make stability a priority did a lot of market building for the ones who did. I personally am very frustrated by this constantly, but there is no way around it that will always work. Someone has to pay the cost of market building, it is a separate cost from stability, and sometimes you can't afford both.
  - ddingus 6y ago
    There isn't. But, what does work far more frequently is to get the solution robust early. The longer it gets put off, the more difficult doing it is, both in time, cost, users being requited to do things along the way to support it all.
    - cycloptic 6y ago
      I agree with you, but still someone has to convince the customers to pay for that, and sometimes they won't. I've been on far too many projects where the customer won't even pay for unit tests and gets angry at the suggestion.
      - ddingus 6y ago
        Well, is that a contract scenario? If so, they can pay now, or pay later, just make sure you manage expectations so they actually do pay. If, somehow that ended up on you, of course they refuse! Why pay for a free lunch? So don't allow that. Seriously.
        cycloptic 6y ago
        You're preaching to the choir. I wouldn't work on such a project again, but when you say "manage expectations" what usually happens there is the customer realizes it doesn't match their expectations and then goes somewhere else and finds something that's in their price range. The point is, there is a class of customers that aren't going to pay for this. Ever. They either can't afford it or have decided it's not valuable.
        ddingus 6y ago
        So let them. That's what I do. And I do that because someone, somewhere will pay now, or pay later. Maybe the customer finds someone hungry enough to pay for them. Or, maybe that customer pays hard going through this cycle a few times too. Not my problem and it does not have to be yours.
        cycloptic 6y ago
        To be clear, I was mostly referring to low-or-zero-cost products mentioned previously like gmail, outlook or excel, or any random zero-cost piece of open source you can download on github. If you depend on that stuff then it is your problem, that's a signal that you won't pay the extra cost for stability. The businesses that can afford the extra stability are not using the consumer offering, they pay Google/Microsoft for a long term support contract. (And yes, Xorg, Wayland, GNOME, KDE, and all the other open source Linux desktops are all under the category of random free project on github)
  - ddingus 6y ago
    And there is an argument for not being able to afford the effort in that scenario too. At the least, risk will be higher than it needs to be, and that puts the other validation into question as well.
ddingus 6y ago
Secondly, say growth in user / subscriber base is a high priority. Often is right? When does robustness end up a priority? Could be a very long time, and or never, particularly given the core value proposition and or features intended to deliver it are not themselves validated by "the market" as you say. One solution to this is to pay people to adopt the solution. Another is to deliver features more specific to them. Yet another is to cover it up, make recovery robust, transparent, etc... These are all perfectly fine ways to approach beta type cases, initial userbase, seeding for growth. After that process has shown what the market finds compelling, stability should be right there in the list with the core set of software to build on.
valand 6y ago
In some domains stability and correctness is a feature. You can't omit stability in life-critical software for example. On the other hand software's usefulness can outinfluence unstability, if there are no alternatives.
- cycloptic 6y ago
  Hey, if you have the kind of money that medical companies spend on testing and stability, and you want to spend that on Linux desktop environments, I won't complain. Although it probably is better to spend that on developing life saving devices than it is on fixing outdated desktop paradigms.
  - ddingus 6y ago
    Sidebar: desktop paradigms are hardly outdated. There are competing paradigms now, and that is good, but they have not yet actually reached use value and productivity levels where it is appropriate to say the desktop paradigm is out of date. At the worst, both will become more generally flexible to keep their value to the users.
    - deleted 6y ago
      [deleted]
- ddingus 6y ago
  Serious question: when are there not alternatives? The point being made here is not that it always must be stable. It is all about how often stability is not a priority when it could and or should be. And in the no alternative scenario, it can be compelling to continue to ignore robustness to get growth and lock in. When that happens, stability, robustness often stay in the back seat for a large fraction of the product life cycle. For any given user, the impact may be just low enough to keep them on board too. New features, and asking more money for them, or offering them to make up for that impact can be an ugly cycle leading to users ripe for the picking later on.
  - 6y ago

That's great when the feature set you're talking about has already been validated by the market. When it's not, it's a mistake to focus on that. I believe we call that "premature optimization."

ddingus 6y ago

Many will not evaluate software that is unstable, because that is a clear sign the whole effort is not yet suitable for any meaningful time investment. Play it how you will, of course. I will pass hard personally. Lack of stability is very high on my qualification list. To be blunt, where it exists there are other priority problems. One may just be flashy speed and other sizzle done at the general expense of the solution being robust. May only take an event or two needed to cancel out potential gains from those things. Turn that crank a time or two and many will just get back to work. An attempt or two again? Many will ignore the solution and or have adopted something else. Net result? The team that did not make stability a priority likely did a lot of market building for the ones who did.

cycloptic 6y ago
>The team that did not make stability a priority did a lot of market building for the ones who did. I personally am very frustrated by this constantly, but there is no way around it that will always work. Someone has to pay the cost of market building, it is a separate cost from stability, and sometimes you can't afford both.
- ddingus 6y ago
  There isn't. But, what does work far more frequently is to get the solution robust early. The longer it gets put off, the more difficult doing it is, both in time, cost, users being requited to do things along the way to support it all.
  - cycloptic 6y ago
    I agree with you, but still someone has to convince the customers to pay for that, and sometimes they won't. I've been on far too many projects where the customer won't even pay for unit tests and gets angry at the suggestion.
    - ddingus 6y ago
      Well, is that a contract scenario? If so, they can pay now, or pay later, just make sure you manage expectations so they actually do pay. If, somehow that ended up on you, of course they refuse! Why pay for a free lunch? So don't allow that. Seriously.
      - cycloptic 6y ago
        You're preaching to the choir. I wouldn't work on such a project again, but when you say "manage expectations" what usually happens there is the customer realizes it doesn't match their expectations and then goes somewhere else and finds something that's in their price range. The point is, there is a class of customers that aren't going to pay for this. Ever. They either can't afford it or have decided it's not valuable.
        ddingus 6y ago
        So let them. That's what I do. And I do that because someone, somewhere will pay now, or pay later. Maybe the customer finds someone hungry enough to pay for them. Or, maybe that customer pays hard going through this cycle a few times too. Not my problem and it does not have to be yours.
        cycloptic 6y ago
        To be clear, I was mostly referring to low-or-zero-cost products mentioned previously like gmail, outlook or excel, or any random zero-cost piece of open source you can download on github. If you depend on that stuff then it is your problem, that's a signal that you won't pay the extra cost for stability. The businesses that can afford the extra stability are not using the consumer offering, they pay Google/Microsoft for a long term support contract. (And yes, Xorg, Wayland, GNOME, KDE, and all the other open source Linux desktops are all under the category of random free project on github)
- ddingus 6y ago
  And there is an argument for not being able to afford the effort in that scenario too. At the least, risk will be higher than it needs to be, and that puts the other validation into question as well.

ddingus 6y ago

Secondly, say growth in user / subscriber base is a high priority. Often is right? When does robustness end up a priority? Could be a very long time, and or never, particularly given the core value proposition and or features intended to deliver it are not themselves validated by "the market" as you say. One solution to this is to pay people to adopt the solution. Another is to deliver features more specific to them. Yet another is to cover it up, make recovery robust, transparent, etc... These are all perfectly fine ways to approach beta type cases, initial userbase, seeding for growth. After that process has shown what the market finds compelling, stability should be right there in the list with the core set of software to build on.

valand 6y ago

In some domains stability and correctness is a feature. You can't omit stability in life-critical software for example. On the other hand software's usefulness can outinfluence unstability, if there are no alternatives.

cycloptic 6y ago
Hey, if you have the kind of money that medical companies spend on testing and stability, and you want to spend that on Linux desktop environments, I won't complain. Although it probably is better to spend that on developing life saving devices than it is on fixing outdated desktop paradigms.
- ddingus 6y ago
  Sidebar: desktop paradigms are hardly outdated. There are competing paradigms now, and that is good, but they have not yet actually reached use value and productivity levels where it is appropriate to say the desktop paradigm is out of date. At the worst, both will become more generally flexible to keep their value to the users.
  - deleted 6y ago
    [deleted]
ddingus 6y ago
Serious question: when are there not alternatives? The point being made here is not that it always must be stable. It is all about how often stability is not a priority when it could and or should be. And in the no alternative scenario, it can be compelling to continue to ignore robustness to get growth and lock in. When that happens, stability, robustness often stay in the back seat for a large fraction of the product life cycle. For any given user, the impact may be just low enough to keep them on board too. New features, and asking more money for them, or offering them to make up for that impact can be an ugly cycle leading to users ripe for the picking later on.
- 6y ago