21–30 of 128 posts
Crunch; poor office environments; PMs, sales, marketing, and so on, lying to customers/stakeholders; bad tools; technical debt; or the like; are beyond the control of software developers and contribute greatly to software failure.
Licensing is not the solution. Here are some things that can help: 1) Limit mutations, shared state, and side effects to very small sections of code. The majority of code should be pure functions and immutable code. 2) Tooling and IDE's should have "code coverage" to show where code is pure and referentially transparent and where it is not. 3) Learn from mathematics / computer science. Adopt formal methods and proof…
Maybe license people who can demonstrate that they really understand this stuff then?
The analogy between software "engineering" and structural engineering is used a lot to point out the failures of software. I think this analogy is a category mistake caused entirely by the misapplication of the word "engineer" to software developers. We have already solved large areas of common classes of bugs at the language level, through strong static typing, memory safety and safe concurrency (Rust is the vanguar…
Only when the cost of failure exceeds the cost of quality will we see real improvements. The company producing the software should bear this burden. Licensure for software developers will only benefit the professional liability insurance industry.
The analogy between software "engineering" and structural engineering is used a lot to point out the failures of software. I think this analogy is a category mistake caused entirely by the misapplication of the word "engineer" to software developers. We have already solved large areas of common classes of bugs at the language level, through strong static typing, memory safety and safe concurrency (Rust is the vanguar…
Is it? you didn't say how it's misapplied.
The analogy between software "engineering" and structural engineering is used a lot to point out the failures of software. I think this analogy is a category mistake caused entirely by the misapplication of the word "engineer" to software developers. We have already solved large areas of common classes of bugs at the language level, through strong static typing, memory safety and safe concurrency (Rust is the vanguar…
None of the above changes the discussion. It's a very elaborate way of saying "writing correct software is hard". You know what's also hard to do correctly? Designing airplanes. Building skyscrapers. It's not that their designs are made flawless, it's that (in theory) the sheer volume of man-hours spent pouring over every minute detail of them, incorporating lessons learned from every failure that's ever happened in…
It's hard to make a safe building, and it's hard to make safe software. The difference is it's (often) incredibly obvious that a building isn't safe the moment you step into it. In software it's sometimes pretty much impossible to tell the difference between a stone temple and a house of cards.
Earlier quoted context omitted.
None of the above changes the discussion. It's a very elaborate way of saying "writing correct software is hard". You know what's also hard to do correctly? Designing airplanes. Building skyscrapers. It's not that their designs are made flawless, it's that (in theory) the sheer volume of man-hours spent pouring over every minute detail of them, incorporating lessons learned from every failure that's ever happened in…
Perhaps one of the reasons for this is that software doesn't allow humans any way of leveraging our evolved "danger detectors". It's hard to make a safe building, and it's hard to make safe software. The difference is it's (often) incredibly obvious that a building isn't safe the moment you step into it. In software it's sometimes pretty much impossible to tell the difference between a stone temple and a house of car…
Nothing new under the sun... MISRA C and Autosar were introduced around 1998, so we can also say standards for safe software are there for decades (around 2 decades but always). You still get companies skipping best practices, guidlines, etc. What is funny you get the same stuff in construction industry. Companies take shortcuts, architects take shortcuts and there are buildings, bridges collapsing. I just don't like…