Everything is broken (2014)

Absolutely agreed.

I wrote the above because I'm frustrated by how often these conversations lead to either calls for more diligence by individual programmers (who are both average and likely working in broken systems), or draconian oversight approaches that amount to treating website developers as though they're designing bridges.

The really interesting things in this domain aren't attempts to force programmers to do a better job, but to make doing a better job easier. It's stuff like Rust attempting to break new ground in safe-by-default memory management, or Let’s Encrypt lowering the bar to getting set up with TLS. Oauth has some downsides, but it's certainly helped move us away from a world where every random site makes its own sloppy attempt to manage user auth. For that matter, IDEs deserve credit for reacting to common classes of mistake; defining a local variable then operating on the input instead is the sort of thing that's easier to catch with an automated warning than with diligence or even tests.

This sort of change has already taken web reliability from "sketchy at best" to "surprisingly good"; common hosts like AWS make basic load balancing and scaling straightforward, and CDNs and DDoS mitigation have become increasingly standard. We're not going to be free of bugs anytime soon, but I think there's good reason to expect actual progress.

This is a huge point, thank you.

I frequently see these discussions go down the road of personal responsibility, as in "you can't just say that it's ok for you to build things poorly because someone else would have done it if you didn't". Which is narrowly true, but strongly implies that bad code comes from individual programmers choosing to do things the easy way. The reality is that individual programmers can't choose to code this way, certainly not outside OSS. It's a structural difference that requires resources to enact.

> it seems likely that our society literally could not afford it... we've built a society which is largely based on software, and been able to afford it as a society only because it's largely based on crappy software.

And so there's the second major issue.

We're producing software at the sort of pace associated with simple consumer goods. If you're designing a new desk organizer, you can do it without much testing, meeting basic standards like "won't fall apart quickly during normal use" and "isn't made of something poisonous to touch". An engineer might well be involved, but they're looking at issues like ease of manufacture and shipment. Someone designing a basic website or app faces the same conditions: the product will fail if it doesn't work right or is unreliable, and they might face legal trouble if it directly causes harm during normal use.

I keep seeing people - including smart, influential programmers - suggest that software development lacks oversight and needs rigorous professional organizations and licenses to practice. Yonatan Zunger, as an example, draws a comparison to bridge collapses and the development of nuclear weapons, then a proposes a licensing regime like those in civil engineering, law, and medicine. (https://twitter.com/yonatanzunger/status/975545527973462016?...)

Frankly, this seems nuts to me. 99.9%+ of software development is lower-stakes than bridge design, and it has enough benefits that constraining it to the pace and price of bridge design has real downsides.

I do see obvious spaces for improvement, like ensuring that there are meaningful costs for companies that lose PII while neglecting basic precautions. But if we're going to keep producing software at even a significant fraction of what we do today, there's probably no way around falling far short of 'best practices' development.

All of that is now thrown out the window in the mad hacking frenzy to make progress on the stupid "points" and try and show progress at the dreaded daily standup meeting (even though it's not supposed to be a progress meeting).

Then to make it worse, various team's progress are compared by looking at "points completed" without any kind of normalization of difficulty or risk for the different teams.

Then the final insult is the whole debacle is deemed a "success" because we've "switched to Agile", thereby checking off a box that some CTO with too much time on his hands read about in some MIT technology review.

I would actively refuse any job offering "Agile development" unless they had a very practical & pragmatic way of implementing it. The only one getting any benefits from this crap are the Agile consultants and the PMs.