The History of Software Engineering


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

Registration Link
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)


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 (, 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.




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.