Post #1460850

2025-12-28 04:26 UTC

@deliverator @cwg1231 I guess my point with that digression is that engineering is characterized by exactly two things—ethics and rigor—neither of which is practiced by the overwhelming majority of programmers. Formal verification isn’t a total solution. A specification can still be bad in plenty of ways, but the software built to meet that specification can be correct. It’s difficult to do, but every real engineering discipline is difficult, and they don’t have correct solutions.

Replies (1)

@cwg1231@defcon.social 2025-12-28 10:46

@bob_zim @deliverator excellent points all around. Regarding rigor, something that absolutely needs to enter the public discussion sphere is confidence metrics for probabilistic software (i.e. any machine learning algorithm ever, especially computer vison). Any probabilistic algorithm being marketed without a probability disclosure is wildly irresponsible and should be publicly shamed. I’d go as far as saying probability disclosures ought to be legally mandated, as well as disclosure of the dataset used to produce that measurement. While software doesn’t decay in the literal sense, it does decay metaphorically. Vulnerabilities are found and need to be patched. Dependencies become deprecated or unmaintained.We run out of seconds since 1 January 1970 countable by a signed 32 bit integer. The left pad incident was a wake-up call for dependency maintenance. I’m vaguely aware of some frameworks for assessing the risk added to your project by a dependency, but I’ve never heard of a dependency being excluded from a project because of its risk. In that sense, we’re still in the fuck around and find out stage of software development. I hope we can change that soon.

Open ##1460851