5/20/2019 What Should We Do to Prevent Software from Failing?

| Hacker News

Hacker News new | past | comments | ask | show | jobs | submit login

What Should We Do to Prevent Software from Failing? (mit.edu)

13 points by sarapeyton 2 hours ago | hide | past | web | favorite | 13 comments

add comment

efficax 16 minutes ago [-]

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 vanguard here but there are lots of languages that tackle these
problems in effective ways).
Institutional inertia (technical debt) is the only reason why we can't apply these solutions to all software. I work on a
PHP app with code that goes back 15 years. To convert it to rust we'd have to invest basically the same as the
operating cost of the company. That'll never happen.
Once "safe" languages are used, there are still bugs of course. But what are those bugs? Failures of thought, plain
and simple. Structural engineers work within the limits of physical reality and these constraints greatly limit the
range of possible creation, thus also the range of possible failure.
Software has limits too, in memory, storage and processing capacity. But otherwise it works entirely in the realm of
pure thought.
Well defined specifications that can be turned into concrete tests can solve a lot of these problems, too. (But this is
also very expensive).
But even if you have specs and tests, there is no magic formula for ensuring your ideas are always sound. If the idea
is wrong you can't even write tests to ensure it's correct. "Correctly" functioning components can have complex,
difficult to predict side-effects when composed into complex systems.
We do have everything we need to write highly reliable software. But solving the software failure problem is the
same task as solving the erroneous thinking problem. I don't know that we meat-sacks can "solve" that problem.
reply

degenerate 0 minutes ago [-]

I've heard the analogy of a software developer to a mechanic, and I like it much more.
Developer = Mechanic
Computer = Car
Make = Language
Model = Platform
Year = Version
A mechanic is licensed by ASE to work on cars in the USA and there are 50 different certifications [1],
depending on the type of car/truck/bus. I don't want to see software development go this route, where
developers have to get multiple certifications to prove they can work on a language or platform. It would be
draining and force devs into silos. And as the parent comment mentions, software is an "idea" problem and
not a structural/foundational one. Unless your developer is a certified genius, what good is his certification?
[1] https://en.wikipedia.org/wiki/Automotive_Service_Excellence
reply

pron 2 minutes ago [-]

> there is no magic formula for ensuring your ideas are always sound. If the idea is wrong you can't even
write tests to ensure it's correct.
There are two parts to this. A wrong idea as in building the wrong product, and a wrong idea as in building the
product wrong. There aren't any mechanical processes to protect against the first, but building the wrong
product is rarely catastrophic (maybe only from a business perspective), and even if it is, it is usually not the
software developer's fault. But as to building the product wrong, there are processes and tools that can help --
a lot -- like TLA+, which is slowly gaining momentum and has completely changed the way I think about
software. Tools like TLA+ are extremely powerful at tackling those "complex, difficult to predict side-effects
when composed into complex systems", but they don't replace careful thinking, they only help you with
attacking complexity once you have decided to think hard about the problem. Getting developers to think hard
before or during the development process -- but not while typing code -- is a cultural shift.
reply

jonahss 3 minutes ago [-]

Licensing isn't the solution here. Software changes too quickly, while institutionalized tests and textbooks, and
certifications move incredibly slowly. Treating this industry the same as others will hopelessly slow down the already
glacial pace of government software, while innovation will continue outside the system.

https://news.ycombinator.com/item?id=19960529 1/2
5/20/2019 What Should We Do to Prevent Software from Failing? | Hacker News
Software is a different realm, as other commenters point out. When faced with a problem in the software world,
what's the solution? More software!
The accrediting bodies that regulators might want to form should focus on free test suites and tools for gauging
security. Static code analyzers, auto penetration testers, something along these lines.
Regulate the quality of the software, not the software developers. It's easier to objectively test.
reply

skaomatic 30 minutes ago [-]

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.
reply

ozim 22 minutes ago [-]

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 dichotomy "proper engineers, mechanical, construction", "kids in the fog, software devs". There are
tons of reliable software, and tons of buildings that might collapse tomorrow because of wind/temperature/vibrations
which never were considered by any builder or architect...
reply

Crinus 34 minutes ago [-]

"All of these professionals have years of schooling and relevant work experience and have passed rigorous
certification exams. [...] To start, coders who work on critical infrastructure should have a professional accreditation
framework that issues licenses."
"mit.edu"
Uh, huh.
reply

Jtsummers 13 minutes ago [-]

This is the MIT Sloan Management Review, not the university itself. The author never attended the university
(based on his LinkedIn profile), rather he attended the University of Waterloo.
reply

daenz 40 minutes ago [-]

So...write a bug, lose your software license? Sounds like fun.
reply

pron 16 minutes ago [-]

Most building "bugs" don't result in harsh sanctions. Only catastrophic (or potentially catastrophic) ones, done
with some negligence do.
reply

naringas 43 minutes ago [-]

ah, here we go
fast forward 25 years and we'll need a government approved license to open dev tools in a browser.
I hope I am wrong.
reply

brootstrap 21 minutes ago [-]

Yeah i think this is the 'software engineers are not REAL engineers'. There is a fair argument on both sides and
the article raises an interesting point. Perhaps the root cause is how new & rapid all this tech has come across
our world. Folks have been building things thousands of years right?
We've only been building scalable docker microservice agile jira lambda functions for a few years now. Curious
to see where time takes us. Change takes a while to come along, companies and people have been getting
hacked for many years but i havent heard any whispers of change.
reply

taylodl 44 minutes ago [-]

I certainly don't disagree but I'd be interested in discussing the nature of the licensing.
reply

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search:

https://news.ycombinator.com/item?id=19960529 2/2