3 ms·

This is false. Its just that the costs of low quality code are much less obvious and harder to measure then the dev time. But the ammount of bad code just piles

by Xeamek 3y ago

This is false. Its just that the costs of low quality code are much less obvious and harder to measure then the dev time. But the ammount of bad code just piles on itself over and over and over and we end up in a world where hardwares becomes incrementally faster while software becomes slower and slower, and more bugier. I mean, in the strict sense of the world an individual company will not pay those costs, but on a societal scale, how much time (and thus money) is wasted daily by all the people who are waiting 30secconds for windows explorer to load? If your app have millions of users, literally every additional second your app wastes multiplies to tangential numbers. It's akin to pollution, really: Individual company making 'dirty' things won't see the consequences. But scale this mindset out and suddenly we wake up in a world when trillions of dollars are spend to counteract those effects.

groestl 3y ago
> This is false. I wonder where you get the confidence to make such a strong statement, which is clearly not warranted. I want to challenge you to broaden your view a bit: Not a lot of software is like Windows explorer. Not a lot of software is performance critical. A lot of software can do with bugs, with many many bugs, to be honest. A lot of code is run fewer than 100 times, before it's retired. Also, not a lot of software written has many users. Or enough users to support maintaining it. "Pollution" often affects just the author of the software themself. Software is just a means to an end, and the end decides, how much effort was warranted in the first place.
- Xeamek 3y ago
  >Not a lot of software is performance critical. Not being performance critical doesn't mean it is justified to diss-respect users by wasting their time. >A lot of code is run fewer than 100 times, before it's retired. Also, not a lot of software written has many users. Obviously we aren't talking about some simple automation scripts here. >"Pollution" often affects just the author of the software themself. You are misunderstanding the pollution analogy. I'm not talking about polluting the codebase with code smell. I am talking about costs of low quality being non obvious and only revealing themselves at global scale
  - groestl 3y ago
    > Obviously we aren't taking about some simple automation scripts here. This is moving the goalpost, and also ignores the fact that software exists on a spectrum from "simple automation script" to "messaging app used by millions". It seems you have a very narrow view of what software is, or what it is used for, and the constrains that apply when building it.
    - Xeamek 3y ago
      This is not moving a goalpost. Running a program less then 100 times total, across all its user, is just very little for anything that could be considered commercial. That really isn't a controversial statement. So I am simply excluding this category as an extremum.
      - groestl 3y ago
        > Running a program less then 100 times total, across all its user, is just very little for anything that could be considered commercial Running that kind of software for the central bank here. So kind of disputing your statement. > So I am simply excluding this category as an extremum. Which ignores the long tail. Great approach.
        Xeamek 3y ago
        What software are you running that gets less then 100 usages before it gets retired? >Great aproach Unironically better, then trying to make prescriptions as broad and general as possible, because those usually are too generic to carry any actual value
        groestl 3y ago
        Yearly reports. They can be buggy, can be off by millions, due to rounding errors. They can crash. They can run for days. Nobody cares enough to rewrite them, because regulation will change before that effort amortizes. Also note that I wrote "code" originally, because there can be programs which are run very often, but certain code paths are not, so my statement applies even for some parts of popular software. The image I think would be valuable for you to consider is a curve, where 20% of code has 80% of all executions, and 80% of code get's the rest. It makes sense to put in a lot of effort into writing the top 20%, but on any given day it is very likely you'll be working on the lower 80%.

by Xeamek 3y ago

groestl 3y ago

> This is false. I wonder where you get the confidence to make such a strong statement, which is clearly not warranted. I want to challenge you to broaden your view a bit: Not a lot of software is like Windows explorer. Not a lot of software is performance critical. A lot of software can do with bugs, with many many bugs, to be honest. A lot of code is run fewer than 100 times, before it's retired. Also, not a lot of software written has many users. Or enough users to support maintaining it. "Pollution" often affects just the author of the software themself. Software is just a means to an end, and the end decides, how much effort was warranted in the first place.

Xeamek 3y ago
>Not a lot of software is performance critical. Not being performance critical doesn't mean it is justified to diss-respect users by wasting their time. >A lot of code is run fewer than 100 times, before it's retired. Also, not a lot of software written has many users. Obviously we aren't talking about some simple automation scripts here. >"Pollution" often affects just the author of the software themself. You are misunderstanding the pollution analogy. I'm not talking about polluting the codebase with code smell. I am talking about costs of low quality being non obvious and only revealing themselves at global scale
- groestl 3y ago
  > Obviously we aren't taking about some simple automation scripts here. This is moving the goalpost, and also ignores the fact that software exists on a spectrum from "simple automation script" to "messaging app used by millions". It seems you have a very narrow view of what software is, or what it is used for, and the constrains that apply when building it.
  - Xeamek 3y ago
    This is not moving a goalpost. Running a program less then 100 times total, across all its user, is just very little for anything that could be considered commercial. That really isn't a controversial statement. So I am simply excluding this category as an extremum.
    - groestl 3y ago
      > Running a program less then 100 times total, across all its user, is just very little for anything that could be considered commercial Running that kind of software for the central bank here. So kind of disputing your statement. > So I am simply excluding this category as an extremum. Which ignores the long tail. Great approach.
      - Xeamek 3y ago
        What software are you running that gets less then 100 usages before it gets retired? >Great aproach Unironically better, then trying to make prescriptions as broad and general as possible, because those usually are too generic to carry any actual value
        groestl 3y ago
        Yearly reports. They can be buggy, can be off by millions, due to rounding errors. They can crash. They can run for days. Nobody cares enough to rewrite them, because regulation will change before that effort amortizes. Also note that I wrote "code" originally, because there can be programs which are run very often, but certain code paths are not, so my statement applies even for some parts of popular software. The image I think would be valuable for you to consider is a curve, where 20% of code has 80% of all executions, and 80% of code get's the rest. It makes sense to put in a lot of effort into writing the top 20%, but on any given day it is very likely you'll be working on the lower 80%.