The History of Software Engineering


#1

Title: The History of Software Engineering
Date: Wednesday, April 25, 2018
Time: 02:00 PM Eastern Daylight Time
Duration: 1 hour

SPEAKER: Grady Booch, Chief Scientist for Software Engineering, IBM Research; ACM Fellow
MODERATOR: Will Tracz, Lockheed Martin Fellow Emeritus; Former chair; ACM SIGSOFT

Resources:
Registration Link
Computing the Human Experience (Grady Booch’s transmedia project)
Computational Thinking,” ACM Learning Webinar with Grady Booch
Leaders in Computing (Safari, free for ACM Members)
Object-Oriented Analysis and Design with Applications, Third Edition (Safari, free for ACM Members)
Object-Oriented Design with ABAP: A Practical Approach (Skillsoft, free for ACM Members)
Practical C++ Design: From Programming to Architecture (Skillsoft, free for ACM Members)
Refactoring for Software Design Smells (ScienceDirect, free for ACM Members)
The Unified Modeling Language User Guide, Second Edition (Safari, free for ACM Members)


#2

Hi Grady, I’ve been a big fan of your “on architecture” podcast.

Q. On system correctness - my education was in electronic engineering, rather than comp sci, so it’s very instinctive for me to test components as I go (before assembling a broken machine, and having to fault-find afterwards!) Recently I’ve read Eberhard Rechtin’s work (http://blog.mccormack.net.au/heuristics-for-testability), and honestly quite stunned by how much of this knowledge is not taught to software engineers. My favourite heuristics around system testability is “…for a system to meet its acceptance criteria to the satisfaction of all parties, it must be architected, designed and built to do so - no more and no less.” That has direct application today, in BDD, microservices and continuous delivery, but there are problems around concepts like progressive redesign in order to “build quality in”. I think many practitioners misunderstand “build quality in” to mean “write more unit tests”, rather than “modify the intrinsic system design in order to to eliminate classes of failure”, perhaps because they lack deeper training in systems architecture.

So, what should modern software engineering education be taking from more established engineering disciplines? It seems that many trivial correctness problems (for a well-structured monolith) are exacerbated by trends, e.g. microservices and the resulting distributed state machines.

Thanks!

Ken


#3

Would “A History of Software Engineering” not have been a more appropriate title? History is typically a view on history, from a certain perspective. Another perspective will lead to another (view on) history.


#4

Dear Grady,

I did read your classical article and book on Object Oriented Analisys and Design (OOAD) in 1997 and since I have researching on Software Engineering (SE), including SE history. Now, related to your lecture, I’m interesting in your opinion about the real history of SE related to the rivalry between IEEE-CS and ACM since SE invention, and its consequences as discipline.

My argument was developed in a short version on my paper First things first: If software engineering is the solution, then what is the problem? as following:

“In an approach based on the Science & Technology Studies is clear that SE was founded when the interests of the first huge customer of software, the U.S. Department of Defense (DoD) and its contractors, could not defeat the interests of the ACM (the main professional association of that time) in an industry of software, academically strong, but DoD was looking for a silver bullet for its managerial crisis and to control to its huge software projects and to its contractors. So, the software crisis term was coined. In consequence, the First SE Conference was celebrated in Garmisch, in 1968, strangely enough, without the invitation to the ACM. After this, would was evident an intellectual and political hostility towards the ACM. The political intention to replace “computer sciences” with “software engineering” would was so evident. An antagonism arose between the ACM and those whom supported SE and created the IEEE-CS. Today, that historical disagreement has not gone away and it continues a subtle intention for “filing for divorce” between them. In any case, SE was invented in Garmisch, at least in a rhetorical sense as the technical and management discipline that would solve the software crisis. The silver bullet was discovered, finally.”

Q1: What is your opinion about this antagonistic history IEEE-CS vs ACM?

“The main consequence of this history of computing is that SE has not played the major role that it would have wanted. CS did not hesitate and now, more than fifty years after of its foundation, is widely recognized as a science and beyond, it has influenced those others. However, SE succumbed to the outside interests and now it navigates to the drift, without such progress. Now there is no longer reason to such rivalry. The SE did fail and the closest thing to a theory of software is: the SWEBoK supported by the IEEE-CS (made to the image and likeness of the PMBoK Guide), the models for management and organization for software contractors of the CMM-I by Software Engineering Institute (SEI) and recently, the SEMAT Initiative.”

Q2: What is your opinion on the consequences of this antagonism between IEEE-CS vs ACM?

Kind regards,

Jesús Zavala Ruiz


A long version of this argument and history is in my CS thesis Software Engineering: An Epistemological Discussion.


#5

I signed up for this webinar, however, the webinar software ONLY accepts Microsoft or Apple operating systems and does not accept Linux! Consequently, I will NOT be attending it! I would think ACM would not choose a system that does not accept Linux. I guess I am wrong.


#6

You should still be able to attend on Linux, even if the system compatibility test doesn’t make that clear. We are constantly working to make our offerings available to all users, and you might be interested to know that On24 is used by the Linux Foundation for their webcasts.


#7

Hi Grady, When is Agile enough? Risk-management based iterative development was for me a huge step forward and so many of its features seem to be missing in agile, e.g. a governing strategy, creation of silos if you don’t identify a need for architecture, … Are too many organizations simply biting this latest silver bullet?


#8

Dear Grady Booch,

I am eagerly looking forward to your Webinar. Thank you for the “Computing the Human Experience” transmedia project. I hope you would share your valuable insights on the defining moments in the NATO 1968 and 1969 conferences.


#9

Where and when will the recording be available? Thank you.


#10

If you register(ed) you will receive an email notifications within a day or so.


#11

Great presentation! Here are my notes, feel free to use:

Espen Andersen


#12

Thank you for an enjoyable Webinar. Espen Anderson’s notes are quite useful as well.

How do we foster faith in humanity at large ?


#13

As requested, I opened the Survey window to evaluate this presentation but I was presented with an error to the effect that a survey has yet to be created for this webinar.

Suggestions?


#14

This was a very informative survey, especially about the number of women who contributed to the discipline of software engineering. Topics worth adding to this survey include

  • quality assurance (e.g., software testing and model checking in addition to Floyd-Hoare style verification)
  • fault tolerance
  • software engineering education (e.g., professional masters degree programs in the early 1980s at the Wang Institute and at Dartmouth College)