Asee peer logo

Sociology In Software Engineering

Download Paper |


2004 Annual Conference


Salt Lake City, Utah

Publication Date

June 20, 2004

Start Date

June 20, 2004

End Date

June 23, 2004



Conference Session

Academic Standards and Academic Issues

Page Count


Page Numbers

9.1102.1 - 9.1102.13



Permanent URL

Download Count


Request a correction

Paper Authors

author page

Craig Caulfield

author page

G Kohli

author page

S P Maj

Download Paper |

NOTE: The first page of text has been automatically extracted and included below in lieu of an abstract

Sociology in Software Engineering

Craig Caulfield, Gurpreet Kohli , S. Paul Maj

Edith Cowan University, Perth, Western Australia


The sociology of software project management is an often under-represented component in the education and professional development of software engineers even though factors such as team formation, role assignment, motivation, training, hiring, and many other peopleware18 practices have been identified many times as at least equally important to the success of software projects as the technical14,16,18,42,44,45,46. The reasons for this may be two-fold: the seeming arbitrariness of the sociological factors in software development is at odds with the formal and familiar technical aspects; and the lack of suitable tools with which to model and understand human dynamics.

However, these impediments may be overcome. For example, system dynamics is a modelling approach to dynamic socio-technical problems, stemming from the work of Forrester20,21,22 at MIT and since developed36,39,43, that allows a modeller to mix soft variables (morale, perceptions, motivations) with familiar hard variables (time, cost, resources). A system dynamics model is not so much a tool for time-point prediction, but more of an experimental device to see how certain variables might change over time under the influence of unappreciated causal relationships, dynamic complexity, and structural delays. The end result is hopefully a more informed mind set with which to manage the situation at hand13.

By way of illustration, this paper presents some initial results of a system dynamics model based on Frederick Brooks’11 well-known informal law which warns against adding more software developers to a late project for risk of making matters worse. Brooks’ law, the crystallisation of many years of practical software project experience, has been critiqued many times in the literature and generally enjoys wide support, making it a solid basis for any model of the socio-technical aspects of software project management. However, it operates at a high level of aggregation and is most often associated with large-scale software development projects. In contrast, the system dynamics model presented here creates a small- team, small-project environment more likely to be encountered by software engineers in the current market.

Brooks Law

Frederick Brooks was an IBM programmer and hardware architect who in 1964 became the manager of IBM’s OS/360 development. Then and now, OS/360 was one the largest and most complex operating systems ever attempted6,27, and was a significant business risk for IBM given that it would not be backward-compatible with IBM’s older machines19,38. Brooks’ experiences on the OS/360 project and his observations of the industry in general are

Proceedings of the 2004 American Society for Engineering Education Annual Conference & Exposition Copyright © 2004, American Society for Engineering Education

Caulfield, C., & Kohli, G., & Maj, S. P. (2004, June), Sociology In Software Engineering Paper presented at 2004 Annual Conference, Salt Lake City, Utah. 10.18260/1-2--14027

ASEE holds the copyright on this document. It may be read by the public free of charge. Authors may archive their work on personal websites or in institutional repositories with the following citation: © 2004 American Society for Engineering Education. Other scholars may excerpt or quote from these materials with the same citation. When excerpting or quoting from Conference Proceedings, authors should, in addition to noting the ASEE copyright, list all the original authors and their institutions and name the host city of the conference. - Last updated April 1, 2015