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).
Ok wow, that is a fantastic and lucid explanation of both the error and the real-time capabilities of the system. If only our desktop software was as smart today!
In the interview, he mentioned that the folks at MIT wrote the program in high-level-language called MAC (MIT Algebraic Compiler) and hand-compiled it to the machine language of the actual computer which I take is what we see at google code.
Wouldn't it be great if the MAC source would also be available for us to see? After all, that is the context in which the actual software engineering took place. Looking at the resulting assembly might give a somewhat distorted impression of how the work was done.
The Block II AGC also has the mysterious and poorly documented EDRUPT instruction (the name may be a contraction of Ed's Interrupt, after Ed Smally, the programmer who requested it) which is used a total of once in the Apollo software: in the Digital Autopilot of the Lunar Module. At this time, while the general operation of the instruction is understood, the precise details are still hazy, and it is believed to be responsible for problems emulating the LEM AGC
I'm not a hardware guy (so please correct if I'm wrong...seriously), but if it's just that one instruction that has unknown functionality, couldn't they look at the code and the specified functionality (of all the code) and sort of reverse engineer the logic of it? Or find one of the old computers (in a museum or something) and examine the hardware in it?
They'd have to unwrap the instructions (hard-wire, literally) to get to the meat of it, and even then there's no guarantee they'd be able to put it all back together again.
Better that it just remains curious, and that we don't use AGC Version 1.0 for future launch attempts ..
the shuttle software group is one of just four outfits in the world to win the coveted Level 5 ranking of the federal governments Software Engineering Institute (SEI) a measure of the sophistication and reliability of the way they do their work.
I wouldn't put too much faith in SEI CMM. The last company I worked for set up an offshore software shop and staffed it with fresh graduates. A year later they were SEI CMM Level 5 certified, boasted the company. This, mind, was despite them never having delivered a complete project... And much of their actual work being done by "contractors" (who were people laid off in the UK and rehired there at vast expense).
There are actually more level 5's in operation. The certification process is about having the procedures in place, and so it is conceivable that you could get that without a delivery.
It's coded in a really interest dialect. Completely unreadable to me, at least.
I wonder what the Shuttle source looks like. I'd imagine its in a higher level language (C?), and that it's likely been rewritten several times since the 70s. It's amazing to me that people wrote this.
Haskell has a `mode' called Literate Haskell, were everything is a comment, unless you specify otherwise (e.g. enclose it in \begin{code} and \end{code} pairs).
There is definitely a balance, but high-level code, when well written, is self-documenting. Comments should justify why something has been coded the way it has, not tell others what the code does (unless it's justifiably unreadable).
Yes comments should be about intent, the implementation (code) should be obvious. Often when maintaining legacy code the most important thing is to understand what the original programmer wanted to do and why. Not that there aren't some complete idiots writing code - but you can't know that this seemingly stupid thing you see in your editor window wasn't the best decision at the time given some constraint that no longer exists now.
Are you sure? AFAIK the earliest LISP (1958) supported lowercase, PDP-1 (1960) had lowercase, the ancient SAIL keyboards (1960s) even had Greek letters on them.
When you're working in that kind of paradigm they're pretty essential...when you have higher level constructs things are a bit more self explanatory :)
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.