When we think of engineering, we often associate it with rigor, logic, and precision. On the other hand, design evokes creativity, freedom, and artistry. At first glance, these two concepts seem to be at odds with each other. However, as software developers, we often find ourselves navigating the intersection of these two worlds. This blog post explores the relationship between software design and engineering, inspired by Jack Reeves' seminal essay, "Code as Design."
Design or engineering?
As we grow as developers, we expand our focus from solving the next task in the sprint to something we call Software Design.
To myself, this concept of software design seemed contradictory to my title of software engineer. Let’s explore this relationship further. After all, engineering is about precision and logic, while design feels more creative and freeform. I work with designers, they’re the ones that make the complicated UI, right?
Well if we take a look at the definitions, we almost get the reverse definitions.
“Engineering is the creative application of science to solve problems”
“Design is the creation of a plan or specification for the construction of an object or a system.”
Looks like engineering is a creative process and design is the one which has to produce specifications. In fact, we can conclude that an engineering activity produces a design document. That is the final goal of engineering.
Looking at other engineering fields, we see that:
-
Civil engineering produces construction documents.
-
Electrical engineering creates PCB designs.
-
Chemical engineering drafts refinery schematics.
In each case, the design is a design document that guides the production of the final system. But in software engineering, what is the equivalent of these designs? Is it UML diagrams? Technical design documents? Something else entirely? I will answer in a second.
The problem with those documents is that in the real world, they often become outdated as soon as implementation begins. This we all know intuitively.
Looking once again at other engineering disciplines, we see that the design is handed off to a separate manufacturing team.
So who does the manufacturing of software? Is it the developers? That cannot be, the developers are engineers.
I posed enough questions for now. It’s time for some answers.
Source code
In traditional engineering, the design is separate from the production process. But in software, the source code is the design. When we write code, we are not building the system—we are designing it. The actual building is done by compilers, linkers, and runtime environments, which translate our design (source code) into executable software.
Here’s how it works:
-
Source code is compiled into bytecode.
-
Bytecode runs on a virtual machine or server.
-
The runtime environment translates bytecode into machine language, tailored to the specific processor architecture.
This process highlights a key difference between software and traditional engineering: building software is practically free. There are no raw materials, no factories, and no physical constraints. This has profound implications for how we approach software design.
What makes a good software design?
If source code is the design, then what makes a good design? Is it clean code? Design patterns? While these are useful tools, they are not the essence of good design. Instead, a good design is one that closely models the real-world domain of the problem you’re trying to solve.
Consider the astrolabe, an ancient instrument used by astronomers to determine the position of stars and calculate local time at night. The astrolabe is a brilliant example of a supple design—it elegantly models a complex real-world domain and provides a practical solution to a challenging problem.
In software, a supple design is one that:
-
Models the problem domain accurately: The design should reflect the real-world context of the problem.
-
Is iterative and refactorable: Good design emerges through continuous refinement and iteration.
-
Avoids excessive up-front design: Over-engineering upfront can lead to rigidity. Instead, focus on understanding the domain deeply and let the design evolve.
Clean code and design patterns are tools that help us communicate and refine our design, but they are not the end goal. The goal is to create a design that is flexible, understandable, and aligned with the problem domain.
The role of documentation in software design
Traditional documentation—UML diagrams, technical design documents, and the like—still has its place in software engineering. However, it’s important to recognize its limitations:
-
Auxiliary: Documentation supports the design but is not the design itself.
-
Temporary: Documentation often becomes outdated as the code evolves.
-
Communication tool: Documentation is most useful for communicating ideas and decisions to other developers or stakeholders.
In the end, the source code is the ultimate source of truth. It is the living, evolving representation of the design.
Iterative is the way to go
To make a good software design, it must be iterative and incremental. Unlike many traditional engineering disciplines where the design phase is distinct from production, software’s low-cost build-and-test cycle enables us to evolve our design continuously. Rather than producing an immutable, up-front design, our source code acts as a living document—a detailed design that transforms user requirements into an executable system.
Software design is dynamic
In practice, the software design process is dynamic. Developers engage in continuous refinement through cycles of development, testing, and feedback. Here are some key aspects:
-
Rapid prototyping: With modern programming languages and frameworks, creating high fidelity prototypes is both fast and cost-effective. This enables developers to experiment with object oriented design and different design patterns before committing to a final architecture.
-
Iterative testing: Each iteration allows developers to assess new features, gather user feedback, and improve the software structure. This agile approach often contrasts with static UML diagrams or rigid design documents that quickly become outdated.
-
Adaptive documentation: While UML diagrams and process diagrams serve as useful communication interfaces among team members, they are auxiliary to the source code. Emphasizing code readability and thorough design reviews ensures that documentation remains aligned with the software’s functioning.
By treating the source code as both the design and the final product, we encourage a mindset where the design phase is an ongoing process—one that is continually refined to better mirror the problem domain and address evolving user requirements.
Domain Driven Design
As established, the best design is one which closely models the real-world domain of the problem you’re trying to solve. The best method I found to achieve that goal is Domain Driven Design (DDD). At its core, DDD is about modeling your software around the core domain of your application—the central problem that your software is intended to solve.
Understanding Domain Driven Design
-
Modeling the problem domain: DDD encourages developers to focus on the language and concepts of the domain. This means that your software design model should closely align with the real-world concepts that drive user requirements.
-
Ubiquitous language: Establishing a common language across the development team, stakeholders, and even the design team is essential. This shared vocabulary fosters better communication and ensures that user stories and design concepts are understood uniformly.
-
Strategic design decisions: The proposed solution domain often guides which architectural design pattern is most appropriate. For instance, if your software has clearly defined layers of responsibility, a Layered architecture might be the best approach.
Extreme programming and Agile methods
While traditional design methods emphasize extensive planning and documentation, Extreme Programming (XP) takes a more hands-on approach. XP champions practices that directly influence the software coding phase, enabling a more responsive design process.
Key Principles of Extreme Programming
-
Continuous Integration and testing: XP promotes frequent testing and integration, which naturally drives improvements in code readability and ensures that design decisions remain valid over time.
-
Pair programming: Collaborating closely during coding sessions fosters immediate design review and knowledge sharing. This collaboration can surface alternative approaches to solving problems, reinforcing the importance of adaptable software design.
-
Refactoring: In XP, refactoring is not an afterthought—it’s a fundamental practice. By continually refining the code, developers can eliminate irrelevant data and outdated design elements, keeping the design supple and aligned with evolving user requirements.
This active approach to design—where testing, feedback, and refactoring are intertwined—highlights that software design is not a static phase but an ongoing journey toward an ever-improving system.
Supple design and the art of refactoring
A truly effective software design is one that is both flexible and refactorable. The term supple design refers to a design that can gracefully evolve in response to changing requirements and technical constraints.
The role of refactoring
-
Maintaining conceptual integrity: Over time, software systems tend to accumulate technical debt. Refactoring serves as a mechanism to realign the code with its original detailed design and ensure that the software design definition remains valid.
-
Enhancing code readability: Through systematic refactoring, developers can improve code readability, making it easier for the team to understand how components interact and to integrate new features seamlessly.
-
Adapting to change: As user requirements evolve, a supple design supports incremental modifications without necessitating a complete overhaul. This agile approach minimizes the risk of introducing bugs and keeps the software development process efficient.
Embracing refactoring as a core practice ensures that the design remains agile and that the detailed design continues to reflect the true nature of the problem domain.
Conclusion: Code is the design
Software engineering is unique in that the design and production processes are deeply intertwined. The source code is both the blueprint and the final product. This duality requires us to think differently about what it means to design software.
A good software design is not about following rigid rules or applying patterns blindly. It’s about understanding the problem domain deeply, iterating on the design, and creating a system that is flexible, maintainable, and aligned with real-world needs. As Jack Reeves argued, code is the design, and our job as software engineers is to craft that design with care and creativity.
So, the next time you sit down to write code, remember: you’re not just solving a task—you’re designing a system. Embrace the rigor of engineering and the creativity of design, and let your code reflect the best of both worlds.
