Nigel Duckworth wrote: > Interesting page on how they manage code for the Space Shuttle; > > http://www.fastcompany.com/online/06/writestuff.html A great example of how NOT to develop software. Expensive, slow, inefficient. I've recently attended the "Agile Software Development Fundamentals" course from ASPE Tech (www.aspetech.com). I highly recommend it, as well as the book that the course is primarily based on -- "Agile Software Development" by Alistair Cockburn. The principles behind the Agile are summarized in the Agile Manifesto, and the Principles behind the Agile Manifesto: http://www.agilemanifesto.org/principles.html Let's contrast the two philosophies (S: Space Shuttle approach, A: Agile approach). I will be quoting from both Agile documents, as well as the OP's article. S: "At the on-board shuttle group, about one-third of the process of writing software happens before anyone writes a line of code. NASA and the Lockheed Martin group agree in the most minute detail about everything the new code is supposed to do -- and they commit that understanding to paper, with the kind of specificity and precision usually found in blueprints" You can't digest EVERYTHING into a series of simple steps. The specs have to be only *sufficient* for the person reading them to understand the problem and implement the solution. If you want to have rules for everything, then you have to have rules for following the rules. Then you'd need rules describing how to follow the rules for following the rules. It doesn't end. A: "Working software over comprehensive documentation" "Working software is the primary measure of progress." Just enough documentation -- not less, but also not more. At the point where documentation starts becoming a waste of time, stop. Initial documentation will change anyway, no reason to "describe every minute detail" of a feature that will later be dropped or replaced by another feature. " Simplicity--the art of maximizing the amount of work not done--is essential." S: Believes that changes are bad, and should be as difficult as possible to implement. "... no coder changes a single line of code without specs carefully outlining the change. Take the upgrade of the software to permit the shuttle to navigate with Global Positioning Satellites, a change that involves just 1.5% of the program, or 6,366 lines of code. The specs for that one change run 2,500 pages, a volume thicker than a phone book. The specs for the current program fill 30 volumes and run 40,000 pages." 2500 pages of specs for about four pages of code, for about 127 pages of actual code. If it isn't ridiculous, I don't know what is. A: Values "responding to change over following a plan." "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage." Document the change, but don't go overboard. 'Just enough' is enough. S: "Everyone has his or her own small office." With a door, I bet -- to help isolate the programmers from each other. Meetings are infrequent, and extremely boring: "The meeting is a classic NASA performance -- a rehearsal for an almost identical meeting several weeks away. It consists of walking through an enormous packet of data and view -- graphs which describe the progress and status of the software line by line. Except for Keller's occasional asides, the tone is businesslike, almost formal, the view - graphs flashing past as quickly as they can be read, a blur of acronyms, graphs, and charts." A: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." Meetings are very informal, there's a constant flow of information between the programmers. Theory behind the program is more important than the actual code or program details. Collaboration is essential, all programmers are in the same room, pair programming is encouraged. Working software is delivered at frequent, regular intervals (~once every 2 weeks). S: "The whole approach to developing software is intentionally designed not to rely on any particular person." A: Values "individuals and interactions over processes and tools". People are everything. Cockburn cites a study that found no significant correlation between the tools or methodologies and project success. Project success is dependent on the kind of people that are working on it. Software is not being delivered? Fire the poor performers, and replace them with programmers that will deliver good software. One thing I noticed about the article, is its frustrated tone "why can't everybody just be like the Shuttle folks?!" The answer is, their approach goes contrary to the way humans work, and it would not be sustainable in the real business environment. The reason the shuttle folks are producing code that is relatively free of bugs, is not because of "The Process", but because: - The project has a $35M *guaranteed* annual budget. That's $83 per line of code, PER YEAR. And not just new code, but EXISTING code as well! - The project duration is indefinite -- development has been going on for decades. - There is strong resistance to change, which translates to fewer opportunities for errors -- at the expense of flexibility, but that's besides the point. - There are 260 programmers working on the project. About 32 pages of code that rarely changes, per programmer. I'd be interested to know how many lines of new code are added every year. Considering that the number of lines given (420,000) for the last three versions is the same, I would think not many. - The job is very cozy: stable work environment, 8-5 days, five day weeks, with all the government benefits and an average estimated salary of $100k (I'm assuming that since the product is software, most of the $35M budget goes to pay the programmers). I believe this is the biggest contributor to the error-freeness of the code: the project retains the people who really understand how the program works. I don't buy the "intentionally designed not to rely on any particular person" argument -- without people who understand the theory behind the program, the project would be dead. Just imagine how much time it would take to read the 40,000 pages of project documentation. The ironic thing is, despite the tremendous human and financial resources, the group software delivered is STILL BUGGY! I don't understand where the author got the idea of "near-perfect results": the shuttle software is routinely the cause of launch delays, and in the article itself there's an example of the software failing: "The software was confused because of a programming error. As the wrist of the remote arm approached a complete 360-degree rotation, flawed calculations caused the software to think the arm had gone past a complete rotation -- which the software knew was incorrect. The problem had to do with rounding off the answer to an ordinary math problem, but it revealed a cascade of other problems." We're lucky that most software companies are not like the shuttle group. Vitaliy -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist