6 ms·

> Software has no marginal cost. Maybe you've never experienced the difference between writing software for 1000 people and writing software for 1M people, or

> Software has no marginal cost. Maybe you've never experienced the difference between writing software for 1000 people and writing software for 1M people, or (I imagine) 1B. The marginal per-person cost of software is not on shipping. It's on "what kind of weird shit will I now have to do because 1M is a lot of chances for my software to break weirdly, and people have paid for it" > You don't have to worry about quality control and returns. You don't have to worry about quality control and returns if you don't care about quality control or returns.

chromoblob 3y ago
As N of people → ∞, chances for software to break → finite maximum. And for good enough software you should consider that maximum already regardless of the number of users.
- cscheid 3y ago
  > And for good enough software you should consider that maximum already for any number of users. I don't believe such software exists. (And, to be clear, I'm writing from direct, day-job experience.) EDIT: I take it back. SQLite, cURL. Maybe. EDIT2: I can't reply to the SEL4 response, so here goes. I'm a huge fan of verification tools, but consider the Spectre class of bugs. Verification is always done wrt a mathematical model that you've defined after inspecting the world and writing down the properties you want to track. But the world changes, and the chance that the world changes increases with the number of users of your software. That's the nature of the beast.
  - chromoblob 3y ago
    seL4 is a formally verified OS kernel. https://sel4.systems/About/ https://sel4.systems/About/
  - chromoblob 3y ago
    Spectre is a bug in the processor, not in the software. I agree that when you're stuck with unfinalized buggy processors, adding mitigations in software is reasonable. But the processor could be finalized too. When I had a reply I couldn't reply to, I opened the reply separately in a new tab, and there I could reply to it, try this.
    - cscheid 3y ago
      > Spectre is a bug in the processor, not in the software. It's a bug in the processor that causes a bug in the software. It's not a bug in your idealized mathematical model, but try telling that to the people who paid you not to leak private keys. I see my job as an engineer to be to create a product that satisfies the user's expectations (which in this case are eminently reasonable). It matters not one bit that I can point the finger to the chipmakers. I'm still selling something that I now learned doesn't do what I said it would. It's still on me to fix it the best I can. If I care about the product quality, that is.
      - chromoblob 3y ago
        The program must not show bugs when run on a hardware with unforeseeable bugs, you call this reasonable?
        cscheid 3y ago
        And yet that's what every good engineer did when Spectre came out. Same with the Pentium fdiv bugs, and same with a host of microcode bugs that come up all the time. Not my business to decide what you think is reasonable. That's just what happens in the world, and what (in my view) good engineers sign up for.
        chromoblob 3y ago
        The choice is between letting hardware be not finalized and letting that force software to be non-finalizable, and letting software be finalizable and forcing the hardware to be finalized too. I like latter more. Finalized hardware is better by itself as well.
        ChadNauseam 3y ago
        We would all like bug-free hardware, but we won't get it and our job is to write good software in the environment we were given
- hinkley 3y ago
  An important philosophical observation is that in a world of 7 billion people, “miracles” are happening to thousands of people every day. I’m software we deal more with curses than miracles. Those happen every day too.
ysavir 3y ago
That's applicable to websites, where you have to handle requests from all your users, and more users means more requests to handle. But if we're talking about plain old regular software, something that needs no server to operate, and functions perfectly fine offline, something like, say, Photoshop, how different is the impact on the manufacturer when the software is used by 1k users, 1M users, and 1B users? Yes, having 1M or 1B users means more opportunities for the bugs to surface and for people do be upset with the product. But do those scenarios impact the quality of the product for other users? Does they introduce unseen costs to the manufacturer? Do they make the product unprofitable or unsuccessful in anyway? Or does it mean that the manufacturer will have to refund 0.1% of their sales, and only benefit from the 99.9% of sales where the product worked as expected?
- cscheid 3y ago
  > how different is the impact on the manufacturer when the software is used by 1k users, 1M users, and 1B users? _very different_, when the user's environment is different. And 1) you haven't seen shit if you think you can perfectly control the user's environment. 2) every new user is a chance for the environment to bite you. > Do they make the product unprofitable or unsuccessful in anyway? You do your engineer best to try and fight that. But there's absolutely a marginal cost, which is what I was responding to.
  - ysavir 3y ago
    > _very different_, when the user's environment is different. And 1) you haven't seen shit if you think you can perfectly control the user's environment. 2) every new user is a chance for the environment to bite you. Can you provide some examples of this? I'd like more info here, because off of the top of my head, I can think of the following counter-examples: 1. This isn't a new problem. User environment has been an issue ever since software as an industry was born. Specifying minimum specs is a pretty typical thing. And while I don't have depth of knowledge on these challenges or their history, my understanding is that it's only become less of a factor over time. So why is digital software different in this regard? If the industry was able to sustain itself before it went digital, what about the change to digital makes it unsustainable now? 2. Computer games, which are probably a good candidate for the most resource-heavy programs that need an appropriate environment, still largely adhere to a pay once business model. Doesn't this indicate that offline experiences aren't affected by environment to such a degree that a single payment business model isn't problematic? > You do your engineer best to try and fight that. But there's absolutely a marginal cost, which is what I was responding to. It surely has a marginal cost. But is that cost significant, is the question. In particular, significant enough to warrant a recurring payment business model.
hinkley 3y ago
Software has a somewhat inverse relationship to scale as manufacturing. For manufacturing the first one costs millions, and each one after costs hundreds for a time. As you get better you winnow away the equipment or maintenance costs and prices drop. Software use cases experience combinatorics, and almost all useful algorithms have log(n) runtime. Even when Knuth says they are O(1), physics or EE say he’s wrong. There are no economies of scale. Racks don’t get cheaper when you run out of network ports. Cooling doesn’t get cheaper when you run out of roof. Things that failed one time in a million calls now happen every hour instead of twice a month, and actually have to be fixed. It’s death by a million cuts.
therealdrag0 3y ago
I suspect it’s less about chances to break due to dice rolls and more chances to not meet the feature/requirements that change based on varying contexts of users, which create a lot of legal and integration and reqs which require lots of code and maintenance.

chromoblob 3y ago

As N of people → ∞, chances for software to break → finite maximum. And for good enough software you should consider that maximum already regardless of the number of users.

cscheid 3y ago
> And for good enough software you should consider that maximum already for any number of users. I don't believe such software exists. (And, to be clear, I'm writing from direct, day-job experience.) EDIT: I take it back. SQLite, cURL. Maybe. EDIT2: I can't reply to the SEL4 response, so here goes. I'm a huge fan of verification tools, but consider the Spectre class of bugs. Verification is always done wrt a mathematical model that you've defined after inspecting the world and writing down the properties you want to track. But the world changes, and the chance that the world changes increases with the number of users of your software. That's the nature of the beast.
- chromoblob 3y ago
  seL4 is a formally verified OS kernel. https://sel4.systems/About/ https://sel4.systems/About/
- chromoblob 3y ago
  Spectre is a bug in the processor, not in the software. I agree that when you're stuck with unfinalized buggy processors, adding mitigations in software is reasonable. But the processor could be finalized too. When I had a reply I couldn't reply to, I opened the reply separately in a new tab, and there I could reply to it, try this.
  - cscheid 3y ago
    > Spectre is a bug in the processor, not in the software. It's a bug in the processor that causes a bug in the software. It's not a bug in your idealized mathematical model, but try telling that to the people who paid you not to leak private keys. I see my job as an engineer to be to create a product that satisfies the user's expectations (which in this case are eminently reasonable). It matters not one bit that I can point the finger to the chipmakers. I'm still selling something that I now learned doesn't do what I said it would. It's still on me to fix it the best I can. If I care about the product quality, that is.
    - chromoblob 3y ago
      The program must not show bugs when run on a hardware with unforeseeable bugs, you call this reasonable?
      - cscheid 3y ago
        And yet that's what every good engineer did when Spectre came out. Same with the Pentium fdiv bugs, and same with a host of microcode bugs that come up all the time. Not my business to decide what you think is reasonable. That's just what happens in the world, and what (in my view) good engineers sign up for.
        chromoblob 3y ago
        The choice is between letting hardware be not finalized and letting that force software to be non-finalizable, and letting software be finalizable and forcing the hardware to be finalized too. I like latter more. Finalized hardware is better by itself as well.
        ChadNauseam 3y ago
        We would all like bug-free hardware, but we won't get it and our job is to write good software in the environment we were given
hinkley 3y ago
An important philosophical observation is that in a world of 7 billion people, “miracles” are happening to thousands of people every day. I’m software we deal more with curses than miracles. Those happen every day too.

ysavir 3y ago

That's applicable to websites, where you have to handle requests from all your users, and more users means more requests to handle. But if we're talking about plain old regular software, something that needs no server to operate, and functions perfectly fine offline, something like, say, Photoshop, how different is the impact on the manufacturer when the software is used by 1k users, 1M users, and 1B users? Yes, having 1M or 1B users means more opportunities for the bugs to surface and for people do be upset with the product. But do those scenarios impact the quality of the product for other users? Does they introduce unseen costs to the manufacturer? Do they make the product unprofitable or unsuccessful in anyway? Or does it mean that the manufacturer will have to refund 0.1% of their sales, and only benefit from the 99.9% of sales where the product worked as expected?

cscheid 3y ago
> how different is the impact on the manufacturer when the software is used by 1k users, 1M users, and 1B users? _very different_, when the user's environment is different. And 1) you haven't seen shit if you think you can perfectly control the user's environment. 2) every new user is a chance for the environment to bite you. > Do they make the product unprofitable or unsuccessful in anyway? You do your engineer best to try and fight that. But there's absolutely a marginal cost, which is what I was responding to.
- ysavir 3y ago
  > _very different_, when the user's environment is different. And 1) you haven't seen shit if you think you can perfectly control the user's environment. 2) every new user is a chance for the environment to bite you. Can you provide some examples of this? I'd like more info here, because off of the top of my head, I can think of the following counter-examples: 1. This isn't a new problem. User environment has been an issue ever since software as an industry was born. Specifying minimum specs is a pretty typical thing. And while I don't have depth of knowledge on these challenges or their history, my understanding is that it's only become less of a factor over time. So why is digital software different in this regard? If the industry was able to sustain itself before it went digital, what about the change to digital makes it unsustainable now? 2. Computer games, which are probably a good candidate for the most resource-heavy programs that need an appropriate environment, still largely adhere to a pay once business model. Doesn't this indicate that offline experiences aren't affected by environment to such a degree that a single payment business model isn't problematic? > You do your engineer best to try and fight that. But there's absolutely a marginal cost, which is what I was responding to. It surely has a marginal cost. But is that cost significant, is the question. In particular, significant enough to warrant a recurring payment business model.

hinkley 3y ago

Software has a somewhat inverse relationship to scale as manufacturing. For manufacturing the first one costs millions, and each one after costs hundreds for a time. As you get better you winnow away the equipment or maintenance costs and prices drop. Software use cases experience combinatorics, and almost all useful algorithms have log(n) runtime. Even when Knuth says they are O(1), physics or EE say he’s wrong. There are no economies of scale. Racks don’t get cheaper when you run out of network ports. Cooling doesn’t get cheaper when you run out of roof. Things that failed one time in a million calls now happen every hour instead of twice a month, and actually have to be fixed. It’s death by a million cuts.

therealdrag0 3y ago

I suspect it’s less about chances to break due to dice rolls and more chances to not meet the feature/requirements that change based on varying contexts of users, which create a lot of legal and integration and reqs which require lots of code and maintenance.