Look at any tech giant’s job board, and you might notice that they list “Software Engineer” instead of “Software Developer” or “Programmer”. Instead of “Development Manager” or “IT Manager” roles, you’ll often see an “Engineering Manager“, yet our industry has struggled with the difference between programming and engineering. Dave Farley, the co-author of Continuous Delivery, has filled this gap with the book, “Modern Software Engineering: Doing What Works to Build Better Software Faster.”
Who’s this book for?
If your role involves building software, then this book is for you. Newer people in the industry will benefit more from this book by understanding what to focus on to build good software. For more experienced people, Farley offers a solid framework to connect well-known/good practices such as Test Driven Development (TDD), Continuous Delivery (CD), Ports and Adapters to the core ideas of software engineering. Others will benefit from this book by learning a bit more about the history of software development, the ideas of engineering and what that looks like in the software world.
What is the book about?
The book is split into three main sections:
- What is software engineering? – A closer look at engineering as a discipline, the misconceptions and variety of engineering fields and what it means for software.
- Optimise for learning – Five concepts (working iteratively, feedback, incrementalism, empiricism, experimental) that support learning.
- Optimise for managing complexity – Five concepts (modularity, cohesion, separation of concerns, information hiding and abstraction, managing coupling) that help manage complexity.
- Tools to support engineering in software – Concrete tools that a modern software engineer draws upon and what it means to work as a modern software engineer.
What I liked about the book
I found the book accessible and easy to read, with many anecdotes, stories and references for further reading material or research. Here are a few points I want to also highlight in this book review.
- Farley defines software engineering as “the application of an empirical, scientific approach to finding efficient, economic solutions to practical problems in software.” You’ll note he doesn’t describe engineering as the stereotype many people think of – armies of project planners, documentation, big upfront design. If you’ve studied lean, you’ll appreciate how Farley calls out the difference between the product design and manufacturing phases, emphasising that software engineers spend most of their time in the former rather than the latter. If you view software development as a manufacturing problem, then it’s natural to assume lean manufacturing processes apply. If, instead, you see software development as a stream of continuous product design, then it naturally leads to two critical drivers for modern software engineering… optimising for learning and managing complexity.
- If you have worked in technology as long as I have, the concrete practices and principles Farley highlights are not new. However, these ten ideas grouped into two categories provide a simple framing to help others learn more about software engineering. Too many people focus too much on learning the specifics of a technology or approach, and these ten concepts provide a different lens to understand what is truly important to focus on.
- As we wrote Building Evolutionary Architectures, one of the terms we also debated was how to phrase our recommended approach to coupling. Farley also touches on this with the idea of cohesion and coupling, pointing out, “It is ridiculous to imagine a system that has no coupling.” Just like we intentionally avoided advice like “Low coupling” or “Remove coupling”, the goal is to find an “appropriate level”, which we know is complicated because this is subjective, but is the reality of it.
Conclusion: A great addition to the industry
Many books in technology have a very short half-life, either connected to a specific tool, framework or version. Modern Software Engineering is a book that I suspect will be relevant for a long-time to come. It provides a great perspective on what people and teams should focus on if they’re going to “engineer” software systems, regardless of what practices or approaches each person uses.
Like this article? Subscribe to Level Up, a free curated newsletter for leaders in tech offering the best reads on leadership, tech, organisations and processes.
