Question
What is the difference between negative coding and throw-away prototyping?
Answer
"Plan to throw one away..." -Frederick P. Brooks, Jr. (Taken from page 266 of The Mythical Man-Month).
Both negative coding and throw-away prototyping involve eliminating lines of code. But this is the only similarity they have. Negative coding is contrasted from throw-away prototyping in that the former is a good practice for production systems and long-term use whereas the latter is designed to be temporary. Negative coding is the rewriting of code to make it more concise. Rather than adding lines of code the programmer removes them (thus the word negative) while retaining a program's functionality.
Throw-away prototyping is the development of a disposable program or programs to have a customer communicate feedback. Throw-away prototyping is for proof-of-concept ideas and to work closely with the customer for crystallizing the requirements. To take a customer's requirements and design a superficial solution with a high-level language such as Python while being aware that the code will never be used beyond a verification test is an example of a throw-away prototype. Throw-away prototyping is the process of creating a symbolic application in the earliest stages of a software design project with the intent that this initial program is both disposable and merely symbolic (unsuitable for a production system due to performance or security reasons). An illustrative representation of a program can be pithy in that it is the basis of communicating an understanding of many small requirements by a software designer to a customer to confirm or deny satisfaction with the prototype.
Iterative development may involve a series of disposable experiments. Planning on discarding a program allows developers to forgo time-consuming security, performance and "best practice" concerns initially. It also invites greater candor from the customer as the illustrative "application" is intentionally abortive. Developers will then invest time from the beginning of their real solution to handle the multitude of tedious obligations only after the feasibility of the project has been confirmed. Thus they can begin a full software development lifecycle in a language such a C, replete with proper testing given the confidence bestowed by the customer's approval of the illustrative prototype. The first line of code will have been written with the specific requirements in mind that will ultimately be able to handle a production load robustly and securely. To learn more about throw-away prototyping, see page 136 of The Internet Encyclopedia, Volume 3 by Hossein Bidgoli published by John Wiley & Sons in 2004. It can be inappropriate from a business perspective for developers, in some instances, to present a throwaway to a customer (as described on page 116 of The Mythical Man-Month).
Given the rapid profusion of Docker containers, the disposable concept is very popular in the software world today. "[Docker's] architectural philosophy centers around atomic or throwaway containers." (This was taken from page 3 of Docker Up & Running by Matthias & Kane, O'Reilly Press, 2015.)
Throw-away prototyping is also referred to as revolutionary prototyping. (Slide 31 of this presentation confirms that these terms are synonymous; another source proving their equivalent meaning is here.) It seems preferable to hyphenate the term "throw-away" compared to the unhyphenated variation "throwaway." The reason is that two-word, or compound, adjectives that are not well-established nor frequently used should be hyphenated (Grammarbook.com). Additionally a 2004 reference to "throw-away prototyping" uses the hyphenated version (Revolutionary vs. Evolutionary Rapid Prototyping: Balancing Software Productivity and HCI Design Concerns. Center of Excellence in Command, Control, Communications and Intelligence (C3I), by S.P. Overmyer, published by George Mason University, 4400 University Drive, Fairfax, Virginia). This 2004 article also states that revolutionary prototyping is a synonym of throw-away prototyping.
Douglas McIlroy, head of research at Bell Labs when Unix was being created, said "[o]f course mass production, in the sense of limitless replication of a prototype, is trivial for software." (The sources of these statements are here and page 79 of this pdf). He also said "[t]he real hero of programming is the one who writes negative code." (This quote was taken from here.) McIlroy advanced the use of pipes at Bell Labs (the origin of Unix); to read more about this, see this link. He also championed Unix philosophy of having modular components in the 1960s (page 79 of this pdf).