Evolution of software architecture

Welcome to The Pragmatic Engineer! Today, I’m thrilled to be joined by Grady Booch, a true legend in software development. Grady is the Chief Scientist for Software Engineering at IBM, where he leads groundbreaking research in embodied cognition. He’s the mind behind several object-oriented design concepts, a co-author of the Unified Modeling Language, and a founding member of the Agile Alliance and the Hillside Group. Grady has authored six books, hundreds of articles, and holds prestigious titles as an IBM, ACM, and IEEE Fellow, as well as a recipient of the Lovelace Medal (an award for those with outstanding contributions to the advancement of computing). In this episode, we discuss: • What it means to be an IBM Fellow • The evolution of the field of software development • How UML was created, what its goals were, and why Grady disagrees with the direction of later versions of UML • Pivotal moments in software development history • How the software architect role changed over the last 50 years • Why Grady declined to be the Chief Architect of Microsoft – saying no to Bill Gates! • Grady’s take on large language models (LLMs) • Advice to less experienced software engineers • … and much more!

Architecture Philosophy Video

 Complexity Basics — Part II: Types of Systems

Abstraction Philosophy Systems

 A Philosophical Look at System Dynamics

Dartmouth College, Hanover, New Hampshire, Spring of 1977. In this lecture, Donella Meadows takes on a more philosophical concept. How can we bring ourselves to be aware of the assumptions we make as systems thinkers? She asserts that models are a set of assumptions. Donella Meadows defines some of these system dynamics assumptions (such as causal relationships and feedback loops) in this video.

Abstraction Philosophy Video

 Design Principles Behind Smalltalk

The purpose of the Smalltalk project is to provide computer support for the creative spirit in everyone. Our work flows from a vision that includes a creative individual and the best computing hardware available. We have chosen to concentrate on two principle areas of research: a language of description (programming language) that serves as an interface between the models in the human mind and those in computing hardware, and a language of interaction (user interface) that matches the human communication system to that of the computer. Our work has followed a two- to four-year cycle that can be seen to parallel the scientific method: Build an application program within the current system (make an observation) Based on that experience, redesign the language (formulate a theory) Build a new system based on the new design (make a prediction that can be tested) The Smalltalk-80 system marks our fifth time through this cycle. In this article, I present some of the general principles we have observed in the course of our work. While the presentation frequently touches on Smalltalk "motherhood", the principles themselves are more general and should prove useful in evaluating other systems and in guiding future work.

Design OOP Philosophy

 Mental Models: The Best Way to Make Intelligent Decisions

A mental model is simply a compression of how something works. Any idea, belief, or concept can be distilled down into a workable model. While far from perfect, they are a useful way to change perspective, simplify complexity, and solve problems. Mental models help us understand the world. For example, velocity is a mental model that helps you understand that both speed and direction matter. Reciprocity is a mental model that helps you understand how going positive and going first gets the world to do most of the work for you. Margin of Safety is a mental model that helps you understand that things don’t always go as planned. Relativity is a mental model that shows us we have blind spots and how a different vantage point can change everything. The list goes on.

Philosophy

 Why embracing complexity is the real challenge in software today

The reason we can’t just wish away or “fix” complexity is that every solution — whether it’s a technology or methodology — redistributes complexity in some way. Solutions reorganize problems. When microservices emerged, they seemingly solved many of the maintenance and development challenges posed by monolithic architectures

Design Philosophy Software Engineering

 How do committees invent?

When I think about design, I more naturally think about it the other way around: how to decompose the whole into a set of parts that will work together to accomplish the system goals. But of course Conway is right that those parts do have to fit together to produce the intended whole again.

Design Philosophy

 Why Understanding the Problem Domain Matters in Software Development

As software developers, we might think that our main job is to write code and create solutions. But really, our most important job is to understand the problems we're trying to solve. In this article, we'll talk about why it's important to understand the problem domain, why this helps us build better software, and how developers can get better at it.

Design Philosophy Software Development

 Engineering You • Martin Thompson

What are the characteristics of a good software engineer? It's a topic many people would argue endlessly about. This is not surprising given we are effectively living in the era of software alchemy. Some of the best programmers draw on strong scientific and engineering backgrounds and combine this with craft-like coding skills in a virtuous feedback cycle. In this talk, we explore the individual practices and techniques that can help bring out the engineer in you.

Design Philosophy Video

 Everyone Is Still Terrible At Creating Software At Scale

I have a hunch that once people saw the economic potential of software, they started looking for ways to "scale it up" and we haven't stopped searching yet.

Philosophy Software Development