3 ms·

I think the “problem” is that ethical questions and nuanced thinking generally get in the way of “getting things done”. It seems that the software/startup/disru

I think the “problem” is that ethical questions and nuanced thinking generally get in the way of “getting things done”. It seems that the software/startup/disruption community glorifies moving fast, shipping an MVP and then iterating on improving measurable metrics. None of these are conducive to dialectic and thinking carefully about consequences. Heck, the popularity of weak/dynamic typing and REPL-it-till-it-works shows that many programmers today aren’t willing to reason about effects even within their own code... leave alone societal consequences! Nothing wrong with that style of programming as such, but I think it’s a symptom of the ratio of thinking-to-doing that many find comfortable. Software is unique in that it gives us the flexibility to fix bugs after shipping, unlike any other engineering field. Over the last few decades, we seem to have gotten increasingly carried away with emphasis on that feature. Also has to do with the incentive structure encouraged in SV.

schaunwheeler 9y ago
I agree with this. There comes a point (much sooner than most people like to recognize) when quality and safety get sacrificed to just getting things done. However, I think that's a manageable risk. Most focus - and tooling - centered on analytic/technical design rather than implementation has the potential to catch problematic implementations before they're shipped. https://towardsdatascience.com/data-is-a-stakeholder-31bfdb650af0 https://towardsdatascience.com/data-is-a-stakeholder-31bfdb6... It's not fool-proof, of course, and I think a change in perspective away from just moving fast and breaking things would be quite healthy for the industry as a whole.
s73v3r_ 9y ago
I think the problem is, you can fix technical bugs after shipping. It's much, much harder to fix ethical bugs.
- schaunwheeler 9y ago
  Exactly. The cost of fixing a bug after the product is out the door is much higher when the bug is ethical rather than technical. Therefore, don't move the product out the door so quickly. Ethical QA takes time.

schaunwheeler 9y ago

I agree with this. There comes a point (much sooner than most people like to recognize) when quality and safety get sacrificed to just getting things done. However, I think that's a manageable risk. Most focus - and tooling - centered on analytic/technical design rather than implementation has the potential to catch problematic implementations before they're shipped. https://towardsdatascience.com/data-is-a-stakeholder-31bfdb650af0 https://towardsdatascience.com/data-is-a-stakeholder-31bfdb6... It's not fool-proof, of course, and I think a change in perspective away from just moving fast and breaking things would be quite healthy for the industry as a whole.

s73v3r_ 9y ago

I think the problem is, you can fix technical bugs after shipping. It's much, much harder to fix ethical bugs.

schaunwheeler 9y ago
Exactly. The cost of fixing a bug after the product is out the door is much higher when the bug is ethical rather than technical. Therefore, don't move the product out the door so quickly. Ethical QA takes time.