Browse Prior Art Database

Software development process using 'throw away on fail' code

IP.com Disclosure Number: IPCOM000013456D
Original Publication Date: 2000-Nov-01
Included in the Prior Art Database: 2003-Jun-18
Document File: 3 page(s) / 91K

Publishing Venue

IBM

Abstract

Software development process using ‘throw away on fail’ code Disclosed is a new software development process which allows a large system to be created without extensive debugging from the system integrators.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 3

Software development process using 'throw away on fail' code

  Disclosed is a new software development process which allows a
large system to be created without extensive debugging from the
system integrators.

While open source is clearly not applicable for the development
of commercial software, Linux has demonstrated that a large,
geographically distributed community can create a complex working
system. Being able to draw on a ' Linux like community' in order
to develop commercial software would have huge advantages, but
such a community would need to be motivated by something other
than a dislike of a perceived monopoly.

The disclosed software development process allows a huge
community to collaborate together in the creation of commercial
software. Designers design a software in terms of a set of
separate components with well defined interfaces. The components
are advertised on the network with a price attached to the
development of each (Step 1 in the figure). Developers submit
contributions that are collected at a central point (Step 2). The
contributions are tested for correctness both individually and
together, contributions which fail are thrown away (Step 3).
After a given period the price of components for which no correct
implementation exists is increased and the components are
readvertised. Developers are paid as function of how many tests
their implementation passed (Step 4). Different implementations
of components which pass all tests are all kept and one of them
is chosen as the implementation to use in the entire system (for
example choosing the component which uses the least resources).
If later systems tests find the component to be defective, it can
be replaced with one of the other implementations. Moreover, it
might even be possible to do this dynamically, i.e. the software
during its execution replaces a component found to be defective.

The assumption is that it is cheaper to pay many people a small
amount to try and write the same component, rather than paying a
small number of people a lot to do the same task. In the latter,
code which does not work needs to be understood and fixed, while
in the f...