This piece documents the origins of the software factory concept, and in
some ways laments that most of the world has never made good use of it.
The major historian of the software factory is Michael A. Cusumano of M.I.T.
From [1], which is a must reading for the seriously interested, are extracted:
- “Perhaps the earliest proponent, R. W. Bemer of General Electric, made
many proposals that culminated in a 1968 paper [5] suggesting that General
Electric develop a software factory to reduce variability in programmer
productivity through standardized tools, a computer-based interface, and
a historical database useful for financial and management controls. ...
Bemer's paper gave the first working definition of what might constitute
a software factory.”
- “While Bemer focused on standardized tools and controls, M.D. McIlroy
of AT&T emphasized another factory-like concept: systematic reusability
of code when constructing new programs.” [8]
- “Reaction to McIlroy's ideas was mixed ... Nonetheless, by the late
1960s, the term ‘factory’ had arrived in software engineering and was
being associated with computer-aided tools, management-control systems,
modularization, and reusability.”
- “The first company in the world to adopt the term ‘factory’ (actually,
its Japanese equivalent ‘kojo’, which translates to either ‘factory’ or
‘work’') to label a software facility was Hitachi, which founded the
Hitachi Software Works in 1969.”
My copy of this paper came from Don McNamara of Corporate Information
Technology at GE, with a cover note saying “Congratulations! Your vision
has made a permanent impact on our profession.” I cherish it.
Software News of 1987 March, page 38, in an article entitled “‘Factories’
for Software?”, reported McNamara's talk in the distinguished
lecturer series at the Wang Institute. “Design code for re-use, and
register it. Re-use is a secret to productivity”, he said.
The following is verbatim from the Report of the NATO Software Engineering
Conference on 1968 Oct 07-11, pp. 94-95 (Reference [6]):
“The most ambitious plans for a set of tools to aid in the production
of large systems that were presented at the conference were those
contained in a working paper by Bemer.
Bemer: (from ‘Machine-controlled production environment’)
Tools for Technical Control of Production
1. Goals
- Maximizing programmer effectiveness and personnel resources.
- Minimizing time and costs for original production, changes and checkout.
- Maintaining the best-conditioned system from a quality viewpoint.
2. Attainment
By utilizing the machine-controlled production environment, or software
factory. Program construction, checkout and usage are done entirely
within this environment using the tools it contains. Ideally it should
be impossible to produce programs exterior to this environment. This
environment should reside on the computing system intended for use, or
in the case of manufacture of a new system, on the most powerful previous
system available.
3. Functions Provided
a. Service
- Computing power and environment
- A file system
- Compilation
- Building test systems
- Building final systems and distribution
- Information during the process
- Listings/automatically produced flowcharts/indexing
- Index and bibliography of software units
- Directed graph of system linkages
- Current specifications
- User documentation, text editing
- Classification of mistake types
- Production records to predict future production
- Diagnostic aids
- Source language program convertors
- File convertors
b. Control
- Access by programmer
- Code volume
- Documentation matching to program
- Software and hardware configurations, and matching
- Customizing
- Replication and distribution
- Quality control
- Instrumentation
- Labor distribution
- Scheduling and costing
In comments following this text, Ascher Opler said “IBM is also
developing such a system. The cost is enormous, and a vast amount of
hardware is needed”. (Note that, in the following NATO Conference of
1969, a paper was given on IBM's “CLEAR-CASTER” system).
Doug McIlroy, the original exponent of software piece parts [8], said
that “It would be immoral for programmers to automate everybody but
themselves. The equivalent to what Bemer is discussing is done by all
big manufacturers to assist the process of hardware design. However, in
addition to the storage of information provided voluntarily by the
programmers, one should take advantage in such a system of the chance to
accumulate additional information without bothering the programmer”.
As I copy this last comment a third of a century later, it is painful to
know that the software industry has still failed to achieve what McIlroy
foresaw so clearly. Nothing will illustrate this more than the last
paragraph of his paper, properly inserted here because there is no
component more important to the software factory than interchangeable
and reusable piece parts.
“I would like to see components become a dignified branch of software
engineering. I would like to see standard catalogues of routines,
classified by precision, robustness, time-space performance, size
limits, and binding times of parameters. I would like to apply routines
in the catalogue to any one of a large class of often quite different
machines, without too much pain. I do not insist that I be able to
compile a particular routine directly, but I do insist that the
transliteration be essentially direct. expressed in machine independent
terms. I want to have confidence in the quality of the routines. I want
the different types of routine in the catalog that are different in
purpose to be engineered uniformly, so that two similar routines should
be available with similar options, and two options of the same routine
should be interchangeable in situations indifferent to that option.
What I have just asked for is simply industrialism, with programming terms
substituted for some of the more mechanically oriented terms appropriate to
mass production. I think there are considerable areas of software ready,
if not overdue, for this approach.”
Also in the 1968 Report, but too long to copy here, is Reference [7],
created in August of 1966. In pages, it provides 8% of the technical
content. It is a very explicit elaboration of the nature of a software
factory, following on the original concept I presented at IFIP 65 and
68. [2,5]
References:
Note: Numbers in square brackets are the serial numbers in the
master list of my
publications.
- M.F.Cusumano, “The software factory: a historical interpretation”,
IEEE Software Magazine, 1989 March, 23-30.
- [36] R.W.Bemer, “Software systems customized by computer”,
Proc. IFIP Congress 1965, Vol. II, 356, 1965 May 24-29
- [37] R.W.Bemer, “Economics of programming production”, in
Economics of Automatic Data Processing, A.B.Frielink, Ed.,
North Holland Publ. Co., Amsterdam, 1965, 155-166
- [39] R.W.Bemer, “Aspects Economiques de la Production de Software”, in
Mecanographie et Informatique, 1966 May
- [50] R.W.Bemer, “The economics of program production”,
Proc. IFIP Congress 68, Booklet I, 13-14
- [51] R.W.Bemer, “Machine-controlled production environment”,
Report NATO Conf, on Stwe. Engg., Garmisch, 94-95, 1968 Oct 7-11
- [52] R.W.Bemer, “Checklist for planning software system production”,
Report NATO Conf. on Stwe. Engg., Garmisch, 165-180, 1968 Oct 7-11
- M.D. McIlroy, “Mass produced software components”,
Report NATO Conf. on Stwe. Engg., Garmisch, 138-152, 1968 Oct 7-11
- [57] R.W.Bemer, “Manageable software engineering”, in
Software Engineering 1, Proc. COINS III, Academic Press,
New York, London, 1970, 121-138
- [63] R.W.Bemer, “Manageable software engineering”, in
State of the Art Report 1, The Fourth Generation,
InfoTech Intl. Ltd., Maidenhead, Berks., England, 445-465, 1971 Jun
- [66]R.W.Bemer, “A software engineer's workshop: tools and
techniques", in
State of the Art Report 11, Software Engineering,
InfoTech Intl. Ltd., Maidenhead, Berks., England, 273-286, 1972
- [83] R.W.Bemer, “Toward the complete software factory”,
Proc. Honeywell Software Productivity Symp., 651-658, 1977 Apr 26-28
Back to Home Page