4 ms·

> [...] the most visible parts of the industry have some serious ethical issues that nobody seems worried about enough to even start to talk about addressing th

by atmosx 3y ago

> [...] the most visible parts of the industry have some serious ethical issues that nobody seems worried about enough to even start to talk about addressing them. Thanks for sharing. What kind of "ethical issues" are you referring to?

JohnFen 3y ago
There are all sorts of ethical issues -- just take a look at the industry news over the past couple of decades for a taste. But the ones that bother me the most are the ones where we abuse our customers for the sake of profit. Issues like data collection and use, "move fast and break things", removing customer autonomy, etc. are all things I struggle to be OK with, but are all things that are heartily embraced by the industry these days. And don't even get me started on the acceptance of overt law-breaking. Companies like Uber (only an example, they're not the only ones that have done this) achieved success by breaking the law, and overall as an industry, we tend to accept this and even celebrate it -- as long as a successful, profitable business is the result.
- tracker1 3y ago
  I like to think of it as "move fast, don't be afraid to break things, and fix them fast". I've been in workplaces with months long release cycles with multiple versions at various stages of testing and it's incredibly slow, difficult and problematic. I've also worked at places where if code touches the main branch, it's in production in about 5 minutes. In the latter production was broken about half a dozen times in the first year. And it was always fixed in about 10 minutes. In the former, there are bugs that take months to correct. I'm not convinced the latter option isn't the better one. Much like you put up hand rails on stairs, you will put guardrails on your CI/CD pipelines and processes. Do you do this from the start, or along the way. It really depends on what state things are in. Most industries cannot tolerate the development of software as more of an engineering discipline. This is disappointing when the likes of the auto industry doesn't. But it's largely expected otherwise. Software development is a craft discipline, not an engineering one more often than not. Most systems are not life and death critical. It's more akin to making a dog house than a sky scraper most of the time.
  - linguae 3y ago
    "Move fast and break things" was originally meant to refer to agile development methodologies that encourages developers to iterate quickly on their implementations and to encourage a development culture where developers are not afraid to make changes to the codebase. However, I believe the quote "move fast and break things" has unfortunately been used by some people to justify and encourage reckless, socially-damaging behavior by companies and individuals. I believe that's what the poster was referring to when critiquing "move fast and break things."
    - tracker1 3y ago
      Oh, I definitely get it... I also remember an Alt.Net movement (people that liked C#, but didn't like the MS "enterprise" patterns) that had a motto of "running with scissors." Of course, there's also times where intentionally breaking something is the best solution to getting the fix done. From literally deleting the code/class/library that you are replacing and dealing with all the compiler errors as part of the fix. Or similarly, actually shutting off the non-secure protocol servers when the company decree has been to only use secure channels (TLS or similar) for communications, and breaking the systems that are still using the insecure channels after remaining up for years, "just in case."
    - JohnFen 3y ago
      > I believe that's what the poster was referring to when critiquing "move fast and break things." Yes. The original sense of the term was fine and expressed a reasonable thing. Since then, it's been taken much too far and has been applied far outside the development process itself. This attitude is, in my opinion, one of the things that has turned the software industry from being mostly a force for good into a very mixed bag.

by atmosx 3y ago

JohnFen 3y ago

There are all sorts of ethical issues -- just take a look at the industry news over the past couple of decades for a taste. But the ones that bother me the most are the ones where we abuse our customers for the sake of profit. Issues like data collection and use, "move fast and break things", removing customer autonomy, etc. are all things I struggle to be OK with, but are all things that are heartily embraced by the industry these days. And don't even get me started on the acceptance of overt law-breaking. Companies like Uber (only an example, they're not the only ones that have done this) achieved success by breaking the law, and overall as an industry, we tend to accept this and even celebrate it -- as long as a successful, profitable business is the result.

tracker1 3y ago
I like to think of it as "move fast, don't be afraid to break things, and fix them fast". I've been in workplaces with months long release cycles with multiple versions at various stages of testing and it's incredibly slow, difficult and problematic. I've also worked at places where if code touches the main branch, it's in production in about 5 minutes. In the latter production was broken about half a dozen times in the first year. And it was always fixed in about 10 minutes. In the former, there are bugs that take months to correct. I'm not convinced the latter option isn't the better one. Much like you put up hand rails on stairs, you will put guardrails on your CI/CD pipelines and processes. Do you do this from the start, or along the way. It really depends on what state things are in. Most industries cannot tolerate the development of software as more of an engineering discipline. This is disappointing when the likes of the auto industry doesn't. But it's largely expected otherwise. Software development is a craft discipline, not an engineering one more often than not. Most systems are not life and death critical. It's more akin to making a dog house than a sky scraper most of the time.
- linguae 3y ago
  "Move fast and break things" was originally meant to refer to agile development methodologies that encourages developers to iterate quickly on their implementations and to encourage a development culture where developers are not afraid to make changes to the codebase. However, I believe the quote "move fast and break things" has unfortunately been used by some people to justify and encourage reckless, socially-damaging behavior by companies and individuals. I believe that's what the poster was referring to when critiquing "move fast and break things."
  - tracker1 3y ago
    Oh, I definitely get it... I also remember an Alt.Net movement (people that liked C#, but didn't like the MS "enterprise" patterns) that had a motto of "running with scissors." Of course, there's also times where intentionally breaking something is the best solution to getting the fix done. From literally deleting the code/class/library that you are replacing and dealing with all the compiler errors as part of the fix. Or similarly, actually shutting off the non-secure protocol servers when the company decree has been to only use secure channels (TLS or similar) for communications, and breaking the systems that are still using the insecure channels after remaining up for years, "just in case."
  - JohnFen 3y ago
    > I believe that's what the poster was referring to when critiquing "move fast and break things." Yes. The original sense of the term was fine and expressed a reasonable thing. Since then, it's been taken much too far and has been applied far outside the development process itself. This attitude is, in my opinion, one of the things that has turned the software industry from being mostly a force for good into a very mixed bag.