Take the 2-minute tour ×

Cleanroom is a software engineering process that's often mentioned in textbooks. There was some documented use of the process in the 90s (I believe it was used at the NASA Software Engineering Lab), but I haven't heard anything about it years. Does anyone have any direct experience using it on a software project?

share|improve this question
NASA - World class process! Testing, testing, and more testing! –  Martin Blore Mar 6 '11 at 0:27
The overhead involved limits its use to software where bugs could be critical. I don't think any business systems would use it. –  BillThor Mar 6 '11 at 3:41
@BillThor Cleanroom projects report better developer productivity and time estimations beside better quality. I think the daunting overhead only is in the mind of the average manager, that more work up front means more work all the way. –  David Andersson Mar 20 '12 at 5:02
Loral used cleanroom when developing software for the Space Shuttle, and Ericsson/Q-Labs for the OS of a telecom switch. It was in the 80s and 90s afaik. –  David Andersson Mar 20 '12 at 5:03

2 Answers 2

I have heard of only one example of the clean room approach to software development being used in the past 15 years. It was for a nuclear reactor control system. Three teams were used, and it worked like this:

1) One team developed a set of formal specifications that were supposed to precisely define input formats, input frames, the algorithms used on the inputs, and the contents of the output frames. Their input was the 'plain English' specifications produced by the technical reactor team.

2) One team developed a software and hardware implementation from only the specifications. They were to use one particular hardware and software platform.

3) Another team developed a software and hardware implementation from the same specifications. They were to use a different hardware and software platform. (Different CPU, different language, and so on.)

Then, the two completed implementations were to be tested both on simulated and random data. It was expected that the two implementations, given the same input frames, would always 100% agree on every bit of the output frames. If not, the specification should prove one system wrong (or both wrong, I suppose). If the specification could not do so, the specification would be considered wrong.

The theory was that once that two implementations agreed, this 'proved' the specification fully specified the system behavior and that both implementations were correct. In the deployed system, the output of the two systems was to be compared bit for bit and any discrepancy logged and considered a serious flaw.

I bet you're wondering what they did in run time if the two systems disagreed. In that case, a third "scram" system would take over whose sole job was to shut the system down as safely and quickly as possible.

In any event, it didn't work. The two teams never managed to agree, the specifications were always ambiguous, and the plan was scrapped.

share|improve this answer
This sounds more like N-version programming than Cleanroom. –  Lorin Hochstein Aug 13 '11 at 16:20
Yeah, I think you're right. In that case, I've never heard of it being used in the past 15 years. –  David Schwartz Aug 13 '11 at 16:24

I have only heard of, or done, cleanroom in the sense of creating a replacement for another product or an interface to it without any access to the products internals.

Like the original cloning of the IBM PC

share|improve this answer
-1. This doesn't even remotely address the question. –  Jörg W Mittag Mar 6 '11 at 2:44
@Jorg: there's an ambiguity on cleanroom that tricked Martin I fear. Cleanroom can also be used to "clone" a system: 1 team reverse-engineer an application and produce specifications and 1 other, different, isolated team use the specifications to code the clone. This process is meant to avoid copyright issues/accusations of plagiarism. –  Matthieu M. Aug 13 '11 at 12:54

Your Answer


