While the issue of standards has received attention from analysts in science and
technology studies, this attention has tended to focus on either units of measurement or
compatibility standards. Much less attention has been devoted to equally important
standards of practice. These are the procedural or process standards which govern how
technologists go about designing and constructing artifacts. Such standards have a
substantial documented history in the form of engineering codes of practice. As the
embodiment of judgments rendered by a particular community of technological practi
tioners, these standards both reflect and shape the exercise of practitioner judgment.
This article explores both these functions through examples drawn from structural and
software engineering. These examples yield insights regarding both the role of formal
procedural standards in technological practice and the unusual nature of software
technology.
References
1.
Abbott, A.1988. The system of professions : An essay on the division of expert laborChicago: University of Chicago Press.
2.
Ackerman, A.F., and F.J. Buckley.1983. Software standards take shapeDatamation29 (October): 259.
3.
Addis, W.1990. Structural engineering: The nature of theory and designLondon: Ellis Horwood.
4.
Beniger, J.R.1986. The control revolution: Technological and economic origins of the information societyCambridge, MA: Harvard University Press.
5.
Blum, B.1985. Understanding the software paradoxSoftware Engineering Notes10(January): 44.
6.
Branstad, M. and P.B. Powell.1984. Software engineering project standardsIEEE Transactions on Software Engineering10 (January): 73.
Braverman, P.H.1979. Yes, folks, standards are a many-splendored thingComputer12(July): 83.
9.
British Standards Institution (BSI).1988. British standard loading for buildings, part 3: Code of practice for imposed roof loadsLondon: British Standards Institution. Information is reprinted with permission of the BSI.
10.
Brohn, D.M.1982. Structural engineering—a change in philosophyStructural Engineer60A (April): 117-20.
11.
Brohn, D.M., and J. Cowan.1977. Teaching towards an improved understanding of structural behaviourStructural Engineer55 (January): 9-17.
12.
Brooks, F.P., Jr.1982. The mythical man-month: Essays on software engineeringReading, MA: Addison-Wesley.
13.
Bucciarelli, L.L.1994. Designing engineersCambridge, MA: MIT Press.
14.
Buchanan, R.A.1989. The engineers: A history of the engineering professton in Britain, 1750-1914London: Jessica Kingsley.
15.
Buckley, F.1979. A standard for software quality assurance plansComputer12(August): 44.
16.
—. 1984. Perspective on standards in the computer societyComputer17 (August): 126.
17.
The case for voting "no." 1987Structural Engineer65A (February): 72.
18.
The case for voting "yes."1987. Structural Engineer65A (February): 72-73.
19.
Chandler, A.D., Jr.1977. The visible hand: The managerial revolution in American businessCambridge, MA: Belknap Press.
20.
Constant, E.W. II.1980. The origins of the turbojet revolutionBaltimore: Johns Hopkins University Press.
21.
Ferguson, E.S.1992. Engineering and the mind's eyeCambridge : MIT Press.
22.
Friedman, A.L., with D.S. Cornford.1989. Computer systems development: History, organization and implementationChichester, UK: Wiley.
Kraft, P.1977. Programmers and managers: The routinization of computer programming in the United StatesNew York: Springer-Verlag.
26.
Latour, B.1987. Science in actionCambridge: Harvard University Press.
27.
Layton, E.T., Jr.1986. The revolt of the engineers: Social responsibility and the American engineering professionBaltimore: Johns Hopkins University Press.
28.
Misa, T.J.1992. Controversy and closure in technological change: Constructing "steel." In Shaping technologylbuilding society: Studies in sociotechnical change, edited by W. E. Bijker and J. Law, 109-39. Cambridge: MIT Press.
29.
O'Connell, J.1993. Metrology: The creation of universality by the circulation of particularsSocial Studies of Science23:129-73.
Open discussion: Simple codes can stifle structural technology1982. Structural Engineer60A (October): 320-33.
32.
Open discussion: Towards a European code for concrete—Can concise codes be comprehensible and comprehensive?1977. Structural Engineer55 (August): 347-48.
33.
Open discussion: Why not WL/8?1986. Structural Engineer64A (July): 182-86.
34.
Petroski, H.1985. To engineer is human: The role of failure m successful designNew York: St. Martin's.
Proceedings of the ACM AdaTEC future Ada environment workshop. 1985. Software Engineering Notes10 (April): 100.
38.
Roman, G.-C.1982. Letter. Computer15 (July): 8.
39.
Rosengard, P.1983. Conroy draws attention to "the neglected 85 percent" of software life-cycle costsComputer16(July): 125.
40.
Rowe, P.G.1987. Design thinkingCambridge: MIT Press.
41.
Shapiro, S.1994. Boundaries and quandaries: Establishing a professional context for ITInformation Technology & People7 (1): 48-68.
42.
-. 1996. Escaping the mythology that plagues software technology In The responsible software engineer: Selected readings in ITprofessionalism, edited by C. Myers, T. Hall, and D. Pitt, 249-57. London: Springer Verlag.
43.
----. 1997. Splitting the difference: The historical necessity of synthesis in software engineeringIEEE Annals of the History of Computing19(1): 20-54.
44.
Shapiro, S., and S. Woolgar.1995. Understanding software development standards in commercial settings: A project report. Discussion Paper No. 54Uxbridge: Brunei University, Centre for Research into Innovation, Culture and Technology (CRICT).
45.
Shaw, M.1990. Prospects for an engineering discipline of softwareIEEE Software7 (November) : 15-24.
46.
Sinclair, B.1980. A centennial history of the American Society of Mechanical Engineers, 1880-1980Toronto: University of Toronto Press.
47.
Spector, A., and D. Gifford.1986. A computer science perspective on bridge designCommunications of the ACM29 (April): 268-83.
48.
Sunley, J.G., and R.G. Taylor.1981. Simple codes can stifle structural technologyStructural Engineer59A (December): 392-93
49.
. Tierney, M.1993. The evolution of Def-Stan 00-55: A socio-history of a design standard for safety critical software In Social dimensions of systems engineering, edited by P. Quintas, 111-43. Hemel Hempstead: Ellis Horwood.
50.
Vincenti, W.G.1990. What engineers know and how they know it: Analytical studies from aeronautical historyBaltimore: Johns Hopkins University Press.
51.
Wasserman, A.I., L.A. Belady, S.L. Gerhart, E.F. Miller Jr., W.M. Waite, and W.A. Wulf.1978. Software engineering: The turning pointComputer11(September): 31.
