We've talked about "software engineering" before. This is it.
From mixmax's fastcompany link: "Ted Keller, the senior technical manager of the on-board shuttle group, flies to Florida where he signs a document certifying that the software will not endanger the shuttle". That's what's required for real engineering in the end: an engineer to sign off on the plans and to take responsibility if the product fails and people die.
This is alien to most software development, where "software engineering" is, at best, a useful metaphor. This is real software engineering.
It's not really - do anything in avionics or health care and you have to follow similar procedures.
The mistake is to believe that making planes fly through the air and making 140-character text messages fly through the net are the same problem, or thinking that one is "real" engineering and the other is not. I would not want your average Rails developer writing the code that keeps my flight flying. I also would not want your average avionics software developer writing consumer web software.
I've worked on both avionics software and web software, and you're spot-on correct... the procedures and development styles are entirely different. Avionics development is laced with simple, easily-understandable coding techniques shrouded in requirements, verification, and paperwork. And yes, real people do sign off on things. Unlike in the web world, where you can whip out changes every day, it's not uncommon for there to be a delay of months (or even years) between writing a piece of code and deployment. We were working on software for the Boeing 787 about five years ago...
I work on SIL-4 systems for Rail (Transportation, not fancy web framework de-jour) applications .. the code I spent a year slaving over to ensure it is as bug-free as can possibly be rendered, won't ship to our customers until next year, and even they won't be deploying it in field for another year or so after they get done with their own tests. So, I'm looking at having to support that code from a year ago, 3 to 5 years from now.
There's a cost to software that always works correctly. If one of the avionics software engineers I've worked with tried to write a consumer webapp, he'd work so slowly that by the time the app was done, I wouldn't need it anymore.
When Reddit was young, I sent a couple bug reports and feature requests to spez & kn0thing. Within an hour, they had the code done and up on the live site. The cost of that was that their users did the QA, which is simply not acceptable for avionics. But I'd rather have a feature done in an hour that may or may not work than wait a month for a feature that I know will work, but is probably rendered obsolete by developments elsewhere on the web.
He means most people are not willing to pay for their web apps to be as well-specced and thoroughly tested and verified as serious software. That goes both for dotcom companies and end-users who votes with their dollars and simply don't care if a website crashes from time to time.
When I was in school here in Canada, we were told the story of the Therac-25 (http://en.wikipedia.org/wiki/Therac-25). Sadly, we're still dealing with some of the problems that plagued the Therac-25 (e.g., poor error messages, arithmetic overflows, simply assuming that software will run the same on compatible hardware, race conditions, etc.) Sometimes I read workarounds to CPU and other hardware errata in kernel modules/drivers. Given the sort of obscure problems mentioned in that code, I for one would not want to put my John Doe on any sort of certification like this. My hat's off to the guy.
In case "this" is the Apollo 11 source code in the submission:
Don Eyles, a 23-year-old self-described "beatnik" who had just graduated from Boston University and was set the task of programming the software for the Moon landing.http://news.ycombinator.com/item?id=707801
I read somewhere (can't find the link) that Dijkstra said he spoke to Eyles, and asked how he got everything correct. He replied that just a few days before launch, the software simulated the moon's gravity as repulsive, before he fixed it... "so the astronauts were lucky there". Probably apocryphal hearsay, but does chime with the "beatnik" story. EDIT Found it: http://www.reddit.com/r/programming/comments/91vki/don_eyles...
Definately apophycral - from the bbc article linked in the first ycombinator article:
The rope core memories would become know as "LOL memory" after the "little old ladies" who knitted together the software at a factory just outside Boston.
These ladies would sit in pairs with a memory unit between them, threading metres and metres of slender copper wires through and around the cores.
"It's an extremely time-consuming process and it meant that the programs had to be finished and fully tested months in advance," said Mr Eyles.
I got some details wrong, but it's basically right.
Dijkstra spoke to Joel Aron (not Eyles), "head of IBM's Federal Systems Division which had been responsible for the software of the moonshot". It wasn't specifically in the lunar module, but somewhere in the 40,000 LoC. However, the bug was that the moon was repelling; and it was found by accident, 5 days before launch.
See Dijkstra say it in person, at 15:00 in this interview (context starts at 13:40): http://www.cs.utexas.edu/users/EWD/video.html (I haven't linked directly to the 300MB download). Great interview BTW (dutch with subtitles).
From mixmax's fastcompany link: "Ted Keller, the senior technical manager of the on-board shuttle group, flies to Florida where he signs a document certifying that the software will not endanger the shuttle". That's what's required for real engineering in the end: an engineer to sign off on the plans and to take responsibility if the product fails and people die.
This is alien to most software development, where "software engineering" is, at best, a useful metaphor. This is real software engineering.