The Software of Star Wars

Code Reads #7: Parnas's "Star Wars" paper links to the well known paper, "Software Aspects of Strategic Defense Systems", where he quotes a description of what a software developer actually does, "How, then, do we end up with any big programs that work at all? "The answer is simple: Programming is a trial and error craft. People write programs without any expectation that they will be right the first time. They spend at least as much time testing and correcting errors as they spent writing the initial program.""

"With these observations in mind, Parnas casts a cold eye on the SDI project, which aimed to produce working systems that could identify and target incoming enemy missiles in a matter of minutes. The system couldn't be tested under real-world conditions; it would be expected to function effectively even when some of its pieces had been disabled by enemy attack; and it was intended to be foolproof (since, with incoming H-bomb-armed ICBMs, 90 percent wasn't good enough). No such system had ever been built; Parnas maintained that no such system could be built within the next 20 years, using either existing methods or those (like AI or "automatic programming") on the horizon."

Logic is highlighted as the mathematics of programming much like continuous mathematics in electrical and mechanical engineering. A lot of the reasons why SDI was unfeasible was that the requirements gathering - it may seem that the customer is a ruthless, dictatorship, with the finger on total annihalation - but it's rarely true.

There are a couple of important questions that probably have better answers now. Can we provide proofs for code larger than 500 lines (in whatever language)? Is hardware failure considered in these proofs? Is rules based programming more efficient?

I'm glad I found this article, it's good because I vaguely remember hearing that the SDI project was not technically feasible (games like this demonstrate the error of linear scaling) but I had not idea that one of the problems was the development of the software (obvious in retrospect). This is slightly different to the management lessons learnt about the space shuttle but similarly illuminating.

The author of the initial blog entry also interviewed Joel Spolsky in which he mentions the idea of programmer fatigue. His book is available of the 16th of this month, called "Dreaming in Code", it talks about software development and the Chandler project. Maybe setting out to be the OS/360 project of the next generation?

Irrationality

The Strategic Logic of Suicide Terrorism "...there have been 188 separate suicide terrorist attacks between 1980 and 2001. Of these, 179, or 95%, were parts of organized, coherent campaigns, while only nine were isolated or random events. Seven separate disputes have led to suicide terrorist campaigns: the presence of American and French forces in Lebanon, Israeli occupation of West Bank and Gaza, the independence of the Tamil regions of Sri Lanka, the independence of the Kurdish region of Turkey, Russian occupation of Chechnya, Indian occupation of Kashmir, and the presence of American forces on the Saudi Arabian Peninsula."

"The bottom line is that the ferocious escalation of the pace of suicide terrorism that we have witnessed in the past several years cannot be considered irrational or even surprising. Rather, it is simply the result of the lesson that terrorists have quite reasonably learned from their experience of the previous two decades: Suicide terrorism pays."

"Perhaps most important, the close association between foreign military occupations and the growth of suicide terrorist movements in the occupied regions should give pause to those who favor solutions that involve conquering countries in order to transform their political systems. Conquering countries may disrupt terrorist operations in the short term, but it is important to recognize that occupation of more countries may well increase the number of terrorists coming at us."

Link Parking

• Going through the Spring Blogs and another posting: Re: Spring, just another hype? "Spring has had support for prototypes and other instantiation and scoping strategies since the early beginning. There are some limitations...For the ‘Singleton A that needs Prototype B’ problem, Spring provides several options such as lookup-methods, target sources and manual lookups."


• JTA Does Not Equal Automatic Support of Two-Phase Commit! "Now it looks like JOTM is getting (it’s in CVS, and part of a new Jonas reelase) XA recovery, but the release version doesn’t. I really welcome a version of JOTM which can do proper XA recovery. It’ll be great to have that option, but until that’s actually available there’s not really much of a reason you’d ever want to use JOTM in a new Spring app deployed in TomCat."


• Behaviour-Driven Development and JBehave.


• Radio National on the top down (American) vs bottom up (British) army (MP3) and Changing the Army for Counterinsurgency Operations (PDF).


• Pellet 1.3 and a list of SPARQL implementations.