[Brooks75] Brooks, P. Fredrick, The Mythical Man-Month: Essays on Software Engineering , Addison-Wesley, 1975.
[Knuth97] Knuth, Donald E., The Art of Computer Programming, Third Edition, Addison-Wesley, 1997.
[Zelkowitz, Shaw, and Gannon79] Zelkowitz, Marvin V., Shaw, Alan C., and Gannon, John D., Principles of Software Engineering and Design , Prentice Hall, 1979.
Part I: Software Development Environments
- Chapter 1: The Nature of Software Engineering
- Chapter 2: Software Engineering Methods
- Chapter 3: Working in Teams
- Chapter 4: Software as a Product
Chapter 1: The Nature of Software Engineering
Software development and engineering is unlike many professions . Even though it is a technical profession, people issues surrounding both development and management are equally, if not more, important. This book is primarily about the human side to software engineering, and this chapter sets the stage.
Readers will understand that most of the reasons for software development success and failure are people-, not technology-centered.
Readers will be able to discuss the effects of human interaction in software development processes.
How did software engineering become a term ?
Is there a good technical solution to software development problems?
How and why are agile methods considered more people-affirming?
Compare software engineering with other professions with which you are familiar. Reflect: What aspects of the professions did you compare?
Software engineering is boring! Guess who said this? Is it a senior nearing graduation? Is it a disgruntled undergraduate ? No! It is a colleague of one of the authors, a Turing Award winner, one of the most intelligent people in our field. He cuts right into the heart of the subject of this book: if we concentrate only on technical aspects of software engineering, it truly is boring; if we pay attention to the panoply of human activities, it becomes much less so.
Software engineering is a lot like civil engineering, in that many practitioners believe in finding a couple of fundamental tools to solve any problem. Civil engineers can trace most of their solutions to the fields of Statics and Strength of Materials. Chemical engineers concentrate on ever-improving processes, and aeronautical engineers are just now getting powerful predictive tools, after nearly a century of trial-and-error flying.
Software engineering tried to find a best solution for much of its early existence. The North Atlantic Treaty Organization (NATO) conference at Garmish, Germany, in 1968, at which the term software engineering became popularized  was most remarkable in that the attendees came together to share solutions, and wound up sharing problems.
Then followed 20 years of searching for one best way of doing things. This seemed to end with Fred Brooks No Silver Bullet essay in IEEE Computer magazine in 1987 [Brooks 87]. In this article, he pointed out that there appeared to be more than one solution to any software-engineering problem. His reputation was so great that he put the skids on the Computer Aided Software Engineering (CASE) solutions then in vogue .
His article raised the old management versus technology debate in which some hold that software failures (still in the majority of projects in the industry) were caused by management (working with people) issues, rather than by technology. Brooks himself, at a Software Engineering Institute (SEI) curricular workshop, said that things done by large groups ” formally ”were not as successful as those done by small groups ”informally. One of the best examples is PL/I versus Pascal. The former is a combination of COBOL and FORTRAN, two languages built by committees giving structure to a third. Niklaus Wirth built the latter. PL/I never took off, either as a teaching or commercial language. Pascal did as both. More milestones of the software engineering history are presented in Chapter 8, The History of Software Engineering.
At this stage, perhaps one good way to compare more traditional software development is to contrast the way two engineers spend the day. The first is at a conventional workplace, and the second at a workplace with less formality .
 There is some evidence that Douglas Ross used the term software engineering in a course at Massachusetts Institute of Technology (MIT) before the NATO conference.