Four Works That Shaped How I Think as an Engineer

This is not a ranking of the most important works in computer science, nor is it a conventional list of books every software developer should read. It is a personal selection of works that shaped how I understand software, design, communication, complexity, and engineering itself.

The first taught me that object-oriented development is fundamentally about design—not merely about writing classes.

The second demonstrated that information, noise, and communication could be studied with mathematical precision.

The third explained why no language, framework, methodology, or technology can eliminate the essential complexity of software.

The fourth may appear entirely unrelated to engineering.

It is not.

1. Object-Oriented Design with Applications (1991)

Author: Grady Booch

I read Object-Oriented Design with Applications early in my career, and it helped shape how I think about software development.

Many of the technologies, programming languages, tools, and modeling conventions described in the book have evolved or disappeared. The fundamental principles, however, remain remarkably relevant.

Grady Booch presented object-oriented development not simply as a programming technique, but as a disciplined approach to understanding and organizing complex systems.

That distinction matters.

Many developers are introduced to object-oriented programming through language features:

• Classes
• Objects
• Methods
• Properties
• Interfaces
• Inheritance
• Polymorphism

Learning these mechanisms does not automatically teach someone how to design software.

A program may contain hundreds of classes and still have a poor object-oriented design. Classes can become containers for unrelated functions. Inheritance can be introduced where composition would be more appropriate. Dependencies can spread across the entire system. Business rules can become distributed among objects with unclear responsibilities.

Object orientation is not defined by the presence of classes. It is defined by how responsibilities, abstractions, relationships, and behavior are organized.

Booch's work emphasizes several essential principles:

• Abstraction
• Encapsulation
• Modularity
• Hierarchy
• Separation of concerns
• Clearly defined responsibilities
• Relationships between objects
• Iterative development

Abstraction

Abstraction allows engineers to represent the essential characteristics of something without exposing every implementation detail.

A useful abstraction is not simply a copy of a database table or a group of variables placed inside a class. It represents a meaningful concept within the system.

Good abstractions reduce the amount of information an engineer must understand at one time. They create boundaries around complexity.

Encapsulation

Encapsulation protects the internal decisions of one component from the rest of the system.

When implementation details are exposed unnecessarily, every change can affect multiple areas of the application. When those details are properly encapsulated, they can evolve without forcing the entire system to evolve with them.

Encapsulation is therefore not only about declaring fields private. It is about controlling knowledge and limiting dependency.

Modularity

A complex system becomes manageable when it is divided into components with clear purposes and controlled relationships.

The objective is not to create the largest possible number of modules. Excessive fragmentation can make a system more difficult to understand.

The objective is to create meaningful boundaries.

A good module should have a clear responsibility, protect its internal decisions, and expose only what other parts of the system genuinely need.

Hierarchy

Hierarchy helps organize abstractions and relationships at different levels.

However, hierarchy does not mean that inheritance should be used everywhere. Inheritance is only one way to express relationships. Composition, delegation, interfaces, and collaboration between objects may provide better designs.

The value of hierarchy is conceptual organization—not the mechanical creation of complicated inheritance trees.

Iterative Design

One of the most important lessons in Booch's work is that software design evolves.

A complete and perfect design rarely exists before development begins. Engineers refine their understanding as they examine the problem, interact with users, build prototypes, test assumptions, and observe how the system behaves.

This is especially important because software requirements are rarely complete at the beginning of a project. Some requirements are implicit. Others emerge only when users interact with a working system. Business conditions may also change during development.

A design must therefore support refinement rather than assume that every decision can be made correctly in advance.

From Booch's Method to UML

Booch also developed a notation and methodology for object-oriented analysis and design. His work was later combined with the methods of James Rumbaugh and Ivar Jacobson during the development of the Unified Modeling Language, or UML.

The original Booch notation is no longer widely used, and UML itself is used less formally today than during its period of greatest popularity.

That does not reduce the importance of the underlying ideas.

A diagram is valuable only when it improves understanding. The purpose of modeling is not to create documentation for its own sake. It is to make structures, relationships, responsibilities, and system behavior easier to analyze and communicate.

Why It Still Matters

Modern development environments allow engineers to create applications faster than ever. Frameworks generate infrastructure automatically. Cloud platforms provide services that previously required specialized teams. Artificial intelligence can now produce significant amounts of code.

None of these capabilities eliminates the need for design.

Faster code generation can even increase the importance of design. Producing code more quickly is not necessarily useful when the resulting system has weak abstractions, uncontrolled dependencies, duplicated responsibilities, and no coherent architecture.

Booch teaches that object orientation is fundamentally a way of thinking about complexity.

The notation has evolved.

The languages have changed.

The tools have improved.

The design principles remain.

2. A Mathematical Theory of Communication (1948)

Author: Claude E. Shannon

Claude Shannon's A Mathematical Theory of Communication established the foundations of Information Theory.

The paper demonstrated that information could be measured and studied independently of its meaning. It introduced a mathematical framework for understanding how information is represented, transmitted, affected by noise, and recovered.

Many concepts now taken for granted originated from Shannon's work:

• Information entropy
• Redundancy
• Noise
• Channel capacity
• Error detection
• Error correction
• Data compression

Modern computing depends on these principles.

Every time information is stored, transmitted across a network, compressed, encrypted, reconstructed, or protected from corruption, we are working within a world shaped by Shannon.

Software engineers may rarely calculate entropy directly. Nevertheless, his work provides a foundation for understanding why communication systems have limits, why redundancy can be useful, why errors are unavoidable, and how reliable communication can emerge from unreliable channels.

Why It Still Matters

Information Theory continues to influence:

• Networking
• Telecommunications
• Data compression
• Encryption
• Storage systems
• Distributed systems
• Machine learning
• Artificial intelligence

Shannon teaches us that communication is not perfect by default.

Reliable systems must be designed with noise, uncertainty, loss, and failure in mind.

3. No Silver Bullet: Essence and Accidents of Software Engineering (1986)

Author: Frederick P. Brooks Jr.

Few ideas in software engineering have remained as relevant as Brooks' argument that there is no silver bullet.

Brooks explained that no single programming language, methodology, framework, management technique, or technological innovation could produce an order-of-magnitude improvement in software development.

His central distinction was between essential complexity and accidental complexity.

Accidental Complexity

Accidental complexity comes from the tools and mechanisms used to implement a system.

Examples include:

• Repetitive code
• Inadequate programming languages
• Poor development environments
• Manual deployment processes
• Unnecessary technical limitations
• Difficult infrastructure
• Weak integration tools

Technology can reduce this kind of complexity.

Modern programming languages, cloud platforms, automation, containers, frameworks, low-code tools, and artificial intelligence can all make implementation faster and more reliable.

Essential Complexity

Essential complexity comes from the problem itself.

It includes:

• Business rules
• Exceptions
• Conflicting requirements
• Changing conditions
• Human behavior
• Regulatory constraints
• Dependencies between processes
• Incomplete knowledge
• Ambiguous definitions

These difficulties cannot be eliminated simply by introducing a new tool.

A healthcare claims system, for example, is difficult not only because of its code. It is difficult because healthcare rules, contracts, benefits, exceptions, payment models, regulatory obligations, and human decisions are inherently complex.

A better programming language may make the code easier to write. It does not make the business problem simple.

The Modern Silver Bullets

The industry repeatedly presents new technologies as if they will fundamentally eliminate the difficulty of software engineering:

• Artificial intelligence
• Microservices
• Low-code platforms
• Cloud computing
• Containers
• New programming frameworks
• New development methodologies

Each may provide real value.

None eliminates essential complexity.

Microservices can improve deployment independence but introduce network, monitoring, consistency, and operational complexity.

Low-code tools can accelerate common workflows but become restrictive when requirements move beyond their intended model.

Artificial intelligence can generate code and assist with analysis, but it still depends on the quality of the problem definition, available context, validation, and architectural judgment.

Why It Still Matters

Brooks teaches engineers to evaluate technology without surrendering to technological enthusiasm.

A new tool may improve implementation. It cannot replace:

• Domain knowledge
• Analysis
• Judgment
• Communication
• Validation
• Architectural discipline

Software engineering is not primarily the elimination of complexity.

It is the disciplined management of complexity.

4. I Have a Dream (1963)

Author: Martin Luther King Jr.

The inclusion of I Have a Dream in a list beginning with object-oriented design, Information Theory, and software complexity may seem unexpected.

That is precisely why it belongs here.

It is not a technical paper. It does not describe an algorithm, a programming model, or a system architecture.

It teaches something that technical education can easily neglect: engineering must have a human purpose.

Software systems are not isolated mathematical constructions. They influence access to healthcare, employment, education, financial services, communication, privacy, and public information.

They determine:

• Who receives access
• What information is collected
• How individuals are classified
• Which decisions are automated
• Whose errors are detected
• Who bears the consequences when a system fails

A system may be technically correct and still produce an unjust outcome.

A model may be mathematically accurate and still be used irresponsibly.

An automated process may be efficient while denying people a meaningful opportunity to question or correct its decisions.

Martin Luther King Jr.'s speech is a lesson in vision, moral clarity, leadership, and the ability to imagine a better system than the one that currently exists.

Engineers are trained to ask whether something can be built.

Humanism requires us also to ask:

• Why should it be built?
• Whom does it serve?
• Who may be excluded?
• What consequences may it create?
• How will errors affect real people?
• Does it improve human dignity and opportunity?

An engineer without humanism can become a powerful instrument without direction.

Why It Matters to Engineers

Technical competence determines whether a system works.

Human judgment determines whether the system is worth building.

As artificial intelligence and automated decision-making become more influential, this distinction becomes increasingly important.

Engineers are no longer responsible only for implementing instructions. Their decisions may influence how people are evaluated, treated, prioritized, monitored, or denied access to essential services.

Technology does not define progress by itself.

Progress must also be measured by its effect on people.