What do you think?
Rate this book
Modern Software Engineering: Doing What Works to Build Better Software Faster
Improve Your Creativity, Effectiveness, and Ultimately, Your Code In
Modern Software Engineering,
continuous delivery pioneer David Farley helps software professionals think about their work more effectively, manage it more successfully, and genuinely improve the quality of their applications, their lives, and the lives of their colleagues. Writing for programmers, managers, and technical leads at all levels of experience, Farley illuminates durable principles at the heart of effective software development. He distills the discipline into two core exercises: learning and exploration and managing complexity. For each, he defines principles that can help you improve everything from your mindset to the quality of your code, and describes approaches proven to promote success. Farley's ideas and techniques cohere into a unified, scientific, and foundational approach to solving practical software development problems within realistic economic constraints. This general, durable, and pervasive approach to software engineering can help you solve problems you haven't encountered yet, using today's technologies and tomorrow's. It offers you deeper insight into what you do every day, helping you create better software, faster, with more pleasure and personal fulfillment.
Clarify what you're trying to accomplish
Choose your tools based on sensible criteria
Organize work and systems to facilitate continuing incremental progress
Evaluate your progress toward thriving systems, not just more legacy code
Gain more value from experimentation and empiricism
Stay in control as systems grow more complex
Achieve rigor without too much rigidity
Learn from history and experience
Distinguish good new software development ideas from bad ones
Clarify what you're trying to accomplish
Choose your tools based on sensible criteria
Organize work and systems to facilitate continuing incremental progress
Evaluate your progress toward thriving systems, not just more legacy code
Gain more value from experimentation and empiricism
Stay in control as systems grow more complex
Achieve rigor without too much rigidity
Learn from history and experience
Distinguish good new software development ideas from bad ones
256 pages, Paperback
Published December 10, 2021
461 people are currently reading
3472 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 134 reviews
June 28, 2022
Here's another case of possible confirmation bias bingo, like I experienced with Accelerate. Modern Software Engineering is, fortunately, much better written.
It's essentially a 200-page-long essay on what works in software development. It makes a compelling case that a certain set of practices constitute software engineering. This set of practices has little to do with Gantt charts, elaborate plans, comprehensive documentation, separate Q&A teams, etc. but rather the modern (but sill far from universal) practices of test-driven development, continuous delivery, low coupling, and feedback-driven iterative development. The same things that Accelerate suggests, and that I myself cover in Code That Fits in Your Head: Heuristics for Software Engineering.
I'll be honest and admit that I mainly decided to read Modern Software Engineering to check out the competition. The book came out a month after mine, and covers many of the same topics.
The main difference is that Modern Software Engineering is mainly a coherent argument for various practices. There are almost no concrete examples or citations. This is, I think, both a strength and a weakness. It's a strength because the line of reasoning can be applied to many different contexts. The contents are less vulnerable to changes in specific technologies or variations in culture. The disadvantage is similar to my main complaint about The Pragmatic Programmer: It's hard to put these ideas into action if you don't already know how to do this. But if you already know this, then do you need the book?
That's the reason I chose to centre Code That Fits in Your Head around a concrete example, with the danger that the contents become too concrete.
Perhaps these two books might be good companions. Read one for the general concepts, and the other for actual examples of execution.
It's essentially a 200-page-long essay on what works in software development. It makes a compelling case that a certain set of practices constitute software engineering. This set of practices has little to do with Gantt charts, elaborate plans, comprehensive documentation, separate Q&A teams, etc. but rather the modern (but sill far from universal) practices of test-driven development, continuous delivery, low coupling, and feedback-driven iterative development. The same things that Accelerate suggests, and that I myself cover in Code That Fits in Your Head: Heuristics for Software Engineering.
I'll be honest and admit that I mainly decided to read Modern Software Engineering to check out the competition. The book came out a month after mine, and covers many of the same topics.
The main difference is that Modern Software Engineering is mainly a coherent argument for various practices. There are almost no concrete examples or citations. This is, I think, both a strength and a weakness. It's a strength because the line of reasoning can be applied to many different contexts. The contents are less vulnerable to changes in specific technologies or variations in culture. The disadvantage is similar to my main complaint about The Pragmatic Programmer: It's hard to put these ideas into action if you don't already know how to do this. But if you already know this, then do you need the book?
That's the reason I chose to centre Code That Fits in Your Head around a concrete example, with the danger that the contents become too concrete.
Perhaps these two books might be good companions. Read one for the general concepts, and the other for actual examples of execution.
February 15, 2022
Clean Code, Pragmatic Programmer and Continuous Delivery walk into a bar...
"Modern Software Engineering" does feel like the lovechild of these previous titles, giving a more overarching and generalized approach to software engineering, combining important concepts from code readability all the way up to delivery and releasability.
Unfortunately, software engineering is often lacking in terms of actual engineering, with people working more based on guesswork and prayer rather than scientific experimentation and measurable iteration, so Dave tries to lay the foundation for proper engineering work, based off decades of experience from him and other engineers.
All in all, a pretty solid foundational book for modern software engineers willing to take their craft to the next level and focus more on the engineering part of their job.
"Modern Software Engineering" does feel like the lovechild of these previous titles, giving a more overarching and generalized approach to software engineering, combining important concepts from code readability all the way up to delivery and releasability.
Unfortunately, software engineering is often lacking in terms of actual engineering, with people working more based on guesswork and prayer rather than scientific experimentation and measurable iteration, so Dave tries to lay the foundation for proper engineering work, based off decades of experience from him and other engineers.
All in all, a pretty solid foundational book for modern software engineers willing to take their craft to the next level and focus more on the engineering part of their job.
November 29, 2021
I absolutely loved this book, I cannot recommend it highly enough. In fact, I gushed over it so much to Dave after I read an early access version that he did me the very great honour of asking me to write the Foreword!
January 3, 2022
The book over promises and under delivers.
If you really want to read this book visit his youtube channel instead. On video he explains in more depth and provides actionable plans instead of only abstract ideas.
Instead read Software Engineering by Ian Sommervile for the software engineering aspect, read Software architecture by Len bass for the software architecture and finally read devops handbook by Jez humble et. al. Reason is that Modern software engineering tries and fails to convey the same material.
If you really want to read this book visit his youtube channel instead. On video he explains in more depth and provides actionable plans instead of only abstract ideas.
Instead read Software Engineering by Ian Sommervile for the software engineering aspect, read Software architecture by Len bass for the software architecture and finally read devops handbook by Jez humble et. al. Reason is that Modern software engineering tries and fails to convey the same material.
June 17, 2023
The book ‘Modern Software Engineering’ teaches us what ‘Software Engineering’ is all about and which principals and values really matter in our Daily Work.
After introducing the term of Engineering, it divides the tasks of an Engineer in two. You have to become an expert in:
I. managing learning
II. managing complexity.
Managing learning deals with how to gather information and feedback throughout the development process and use it to tweak our working solution to even better outcomes as we learn along the way.
This can be done using a Continious Delivery pipeline that gives us feedback on the releasability of our software.
Managing Complexity deals with how to design the systems that we work on so that they are of high quality, easy to understand and to change, so that we can keep adding value. For example using Modularity and Seperation of Concerns promotes these things.
While being very general, Dave Farley repeatedly praises one practice, that he thinks of being highly effective towards designing better systems (managing complexity): Test-Driven Development.
I highly appreciate the tools and values of this book, because they teach us what is important on a much broader context and remind us that the specific details might not be as important as they seem (which programming language or framework to use…)
Following the principles in the book and applying the two techniques (CD and TDD) should yield in better software faster, Farley almost ‘promises’. And I would sign the contract immediately. 😉
After introducing the term of Engineering, it divides the tasks of an Engineer in two. You have to become an expert in:
I. managing learning
II. managing complexity.
Managing learning deals with how to gather information and feedback throughout the development process and use it to tweak our working solution to even better outcomes as we learn along the way.
This can be done using a Continious Delivery pipeline that gives us feedback on the releasability of our software.
Managing Complexity deals with how to design the systems that we work on so that they are of high quality, easy to understand and to change, so that we can keep adding value. For example using Modularity and Seperation of Concerns promotes these things.
While being very general, Dave Farley repeatedly praises one practice, that he thinks of being highly effective towards designing better systems (managing complexity): Test-Driven Development.
I highly appreciate the tools and values of this book, because they teach us what is important on a much broader context and remind us that the specific details might not be as important as they seem (which programming language or framework to use…)
Following the principles in the book and applying the two techniques (CD and TDD) should yield in better software faster, Farley almost ‘promises’. And I would sign the contract immediately. 😉
May 8, 2022
In general, I am a fan of this author because of his (amazing) educational YouTube channel (“Continuous Delivery”).
Oh, this one book, in my opinion, is fighting for first place in a list of my favorite technical books with “A Philosophy of Software Design” and “Agile Technical Practices Distilled”. Seriously, it’s really good. I love that the author has focused on things that matter in software engineering, and has excellently described them!
1. How important is working iteratively and incrementally, and what is the difference?
2. What is the feedback, and how important it is for software engineers?
3. Cohesion, separation of concerns, abstraction, coupling -> key elements of SE and software design, why?
4. What is engineering, and what’s the difference between software engineers and for example bridge engineers?
Yes, I fell in love with this book. Maybe because I like the philosophical thinking of SE, but… it’s seriously worth reading. 5/5 obviously!
Oh, this one book, in my opinion, is fighting for first place in a list of my favorite technical books with “A Philosophy of Software Design” and “Agile Technical Practices Distilled”. Seriously, it’s really good. I love that the author has focused on things that matter in software engineering, and has excellently described them!
1. How important is working iteratively and incrementally, and what is the difference?
2. What is the feedback, and how important it is for software engineers?
3. Cohesion, separation of concerns, abstraction, coupling -> key elements of SE and software design, why?
4. What is engineering, and what’s the difference between software engineers and for example bridge engineers?
Yes, I fell in love with this book. Maybe because I like the philosophical thinking of SE, but… it’s seriously worth reading. 5/5 obviously!
October 20, 2024
David Farley's foundation of an engineering discipline for software development really resonates with me — mostly, he is confirming my own view on software development. Nevertheless, I did get some new insights and found the book quite inspiring. Unfortunately, the editing could have been better, eliminating some typos and improving the writing. Also, while the author explains why there is so much redundancy in the book, I am not convinced that the extent of redundancy could not have been reduced. 3.5 stars for the overall package, easily 4 or more stars if you ignore the flaws I mentioned.
December 14, 2022
The one useful contribution of this book is in its first two chapters, where the author states his intention to reclaim the "engineering" part of software engineering, compares it with science and craft and proposes that an engineering approach is possible and even necessary for software development.
The rest of the book was supposed to support those intentions but was a disappointment. Despite the title, the ideas presented here (modularity, abstraction, separation of concerns) aren't particularly modern; the techniques insisted upon (XP, TDD, continuous delivery, domain-driven design) are also 15-20 years old . This isn't a problem in itself, but the book doesn't present these techniques as effectively as their canonical sources (or Wikipedia, for that matter), is not a good summary of them and doesn't make a convincing argument about why they achieve the goals introduced at the beginning of the book. The content remains vague and anecdotal, and closely related topics feel stretched to fill several chapters (empiricism/"being experimental", modularity/information hiding/cohesion/separation of concerns).
Instead of this book, I recommend A Philosophy of Software Design, The Pragmatic Programmer, Fundamentals of Software Architecture and The Manager's Path, all of which present truly contemporary takes on the different aspects of the discipline. There may be room for a book that consolidates all of them into one coherent whole, and helps to raise the bar from craftsmanship to engineering, but Modern Software Engineering isn't it.
The rest of the book was supposed to support those intentions but was a disappointment. Despite the title, the ideas presented here (modularity, abstraction, separation of concerns) aren't particularly modern; the techniques insisted upon (XP, TDD, continuous delivery, domain-driven design) are also 15-20 years old . This isn't a problem in itself, but the book doesn't present these techniques as effectively as their canonical sources (or Wikipedia, for that matter), is not a good summary of them and doesn't make a convincing argument about why they achieve the goals introduced at the beginning of the book. The content remains vague and anecdotal, and closely related topics feel stretched to fill several chapters (empiricism/"being experimental", modularity/information hiding/cohesion/separation of concerns).
Instead of this book, I recommend A Philosophy of Software Design, The Pragmatic Programmer, Fundamentals of Software Architecture and The Manager's Path, all of which present truly contemporary takes on the different aspects of the discipline. There may be room for a book that consolidates all of them into one coherent whole, and helps to raise the bar from craftsmanship to engineering, but Modern Software Engineering isn't it.
June 24, 2022
The way Dave Farley defines "Software Engineering" in this book fundamentally shifts it away from all the things I've spent years disassociating myself from. It fundamentally explains why those things are not engineering and why a focus on the wrong part of the engineering metaphor has created confusion.
The book also explains very well how many of the problems of software engineering also exists as challenges for the teams of people delivering software.
I hope this book gets high uptake so we can shed the things from the past that are slowing us down and making our software worse than it could be.
The book also explains very well how many of the problems of software engineering also exists as challenges for the teams of people delivering software.
I hope this book gets high uptake so we can shed the things from the past that are slowing us down and making our software worse than it could be.
December 13, 2021
Everything important about software engineering
Distills everything that feels important about software engineering and still manages to explain everything in an accessible way. It’s more than just a disconnected set of good ideas. It’s a cohesive explanation of why those ideas work and how applying a scientific approach will help us test new ideas when we have them. Really wish this book existed when I got my first programming job, but it’s still been valuable to me 8+ years into my career.
Distills everything that feels important about software engineering and still manages to explain everything in an accessible way. It’s more than just a disconnected set of good ideas. It’s a cohesive explanation of why those ideas work and how applying a scientific approach will help us test new ideas when we have them. Really wish this book existed when I got my first programming job, but it’s still been valuable to me 8+ years into my career.
September 8, 2023
Ok, é um livro sólido, compilando conceitos extremamente importantes para a engenharia de software. Vale a pena ser lido, principalmente se você não tem experiencia suficiente para enxergar valor nos pontos explicados.
Como ponto fraco, não traz nada de novo - o próprio autor admite isso - e é extremamente repetitivo, principalmente nos capítulos iniciais, onde o autor se repete demais para justificar a importancia do livro.
Como ponto fraco, não traz nada de novo - o próprio autor admite isso - e é extremamente repetitivo, principalmente nos capítulos iniciais, onde o autor se repete demais para justificar a importancia do livro.
August 12, 2022
Repetitive (on purpose) and slightly meandering book, but the concepts described are valuable. Would definitely appreciate more concrete examples to add some implementation meat to the conceptual bones
November 14, 2024
Software engineering is a relatively young discipline that’s rapidly evolving. What practices moved software forward thirty years ago are different from what moves them today. Today, most software requires continual-release techniques in the era of Internet speed. In this book, David Farley, an expert in that area and one seasoned in business practices, brings the field up to date with practices that work. Modern Software Engineering provides a good summary informed by reading, personal practice, and industry consulting to guide and enlighten the next generation of developers.
Farley’s development of a financial exchange heavily informs this book’s approach. Conceptually, he is a big proponent of test-driven development (TDD) to guide efficient outcomes. He builds a matrix of guiding practices around TDD and advocates for programming values like modularity, cohesion, and testability. He shows why these values are good to approach software projects and even posits that they should be considered more with data-oriented projects. In so doing, he provides a snapshot of a philosophy of how to advance complex, integrated software.
I am a developer working on data-intensive scientific projects. I honestly don’t use TDD in my development because so much of my work is exploratory. I don’t often know what end goal to test for when I start coding because the terrain is so new. Thus, art often predominates overall over science. I don’t have any qualms with TDD; after extensive attempts, adding it to the workflow has never been efficient for my exploratory projects. I have found TDD extremely useful for certain subprojects with more defined, more stable aims. I believe my exploratory projects are outliers more than the norm, though.
After learning the programming languages themselves, advancing software engineering techniques is certainly the most essential skill for a software developer. The field itself changes, and Farley has brought us all more up to date with a fresh recast. Experienced programmers like myself might quibble about some of the details, but his overall orientation is spot on. It deserves study by anyone producing software, from newbies to the masters. Reading this book is well worth their time to interact with a leading mind about a topic crucial to their work.
Farley’s development of a financial exchange heavily informs this book’s approach. Conceptually, he is a big proponent of test-driven development (TDD) to guide efficient outcomes. He builds a matrix of guiding practices around TDD and advocates for programming values like modularity, cohesion, and testability. He shows why these values are good to approach software projects and even posits that they should be considered more with data-oriented projects. In so doing, he provides a snapshot of a philosophy of how to advance complex, integrated software.
I am a developer working on data-intensive scientific projects. I honestly don’t use TDD in my development because so much of my work is exploratory. I don’t often know what end goal to test for when I start coding because the terrain is so new. Thus, art often predominates overall over science. I don’t have any qualms with TDD; after extensive attempts, adding it to the workflow has never been efficient for my exploratory projects. I have found TDD extremely useful for certain subprojects with more defined, more stable aims. I believe my exploratory projects are outliers more than the norm, though.
After learning the programming languages themselves, advancing software engineering techniques is certainly the most essential skill for a software developer. The field itself changes, and Farley has brought us all more up to date with a fresh recast. Experienced programmers like myself might quibble about some of the details, but his overall orientation is spot on. It deserves study by anyone producing software, from newbies to the masters. Reading this book is well worth their time to interact with a leading mind about a topic crucial to their work.
October 16, 2022
This book is both great and flawed. The first part of the book is excellent and my favorite. The remaining parts are a continuous repetition of `TDD is the only true way`. It didn't provide enough examples, and its reasoning was basically: `I'm an excellent engineer, so just trust me`. The examples were contrived. The typical example was that if you have a function that must persist to a database, you should ideally publish a message somewhere, and that something subscribed to it will proceed to do the heavy work for you. But that part of the system also needs to be tested, and he fails to address that. That has always been my qualm with TDD preachers. It even feels patronizing even.
I still highly recommend it. Read the first part, and then read the Philosophy of Software Design for the second part instead.
I still highly recommend it. Read the first part, and then read the Philosophy of Software Design for the second part instead.
July 17, 2022
I was baited by the title "Modern", but I found nothing modern in the book. It mentioned some basic concepts which are better described in other books. I would recommend Clean Code and Clean Architecture by Robert C. Martin instead of this one. Maybe I do not fit the target audience of this book and it would be more useful to someone who is just starting out, but then yet again there are better books.
February 9, 2024
A very mediocre book from someone interested in being famous. Internally the book's logic barely holds together. It's a useful survey of contemporary beliefs/trends within the main commercial technology consulting and software delivery community of the day.
August 28, 2022
Extremely good book, which lays out fundamental principles which haven´t changed for many decades, that are independent and much more impactful than the choice of current technologies.
October 16, 2024
Throughout Dave’s magnum opus, “Modern Software Engineering”, he highlights major lessons learned over his career, primarily the importance of feedback, iteration, and testability for efficient development work. Many of the ideas discussed can be found on his YouTube channel, “Continuous Delivery”. Read this if you learn better from reading, otherwise check out his channel.
November 23, 2022
Well structured. The author goes to great lenghts to clarify the abstractions, but some of the text can be repetitive and hard to follow. Also, it could do with a few more code examples and real world scenarios. People remember stories, not concepts.
July 6, 2025
This was a great read for anyone who is looking to grow their overall engineering understanding. Driving into core processes like: TDD, design patterns, continuous delivery, and system design, you get a primer on all sorts of facets of development that your team and org should be doing.
July 22, 2024
Nothing new really. Same old principles from classic books.
July 21, 2023
Very good point of view for anybody in software related activities. Must read as also continuous delivery.
Experimentation on steroids with engineering mindset.
Experimentation on steroids with engineering mindset.
June 1, 2025
Way too watery!
Too long. Too repetitive. Too abstract. Too many sidebars.
I didn't like it. Quite a waste of time.
(I have 16 years of software engineering experience myself)
Too long. Too repetitive. Too abstract. Too many sidebars.
I didn't like it. Quite a waste of time.
(I have 16 years of software engineering experience myself)
December 6, 2022
This is not only recommended, this is a must read.
If you write software, and more importantly if you write commercial software, this book is all about the development tools that will improve your business model, the company where you work, your capacity for team work, your efficiency as a developer.
If you write software, and more importantly if you write commercial software, this book is all about the development tools that will improve your business model, the company where you work, your capacity for team work, your efficiency as a developer.
January 18, 2023
Developed a strong urge to try TDD after listening to this book
September 15, 2023
Пережёванные мысли по 10 разу на тему связности, сцепленности и прочего.
March 17, 2024
This is a great book if you are studying software development/engineering or if you just finished your studies and want to make sure you start off your career on the right foot.
If however you have been in the industry for at least a couple of years this book gives little extra value. The underlying ideas are great but the thing is you are probably doing all of that. Well perhaps not TDD but mostly everything else.
And on that note, this book is basically a love letter to TDD which is not necessarily bad but be prepared that it's mentioned A LOT.
If however you have been in the industry for at least a couple of years this book gives little extra value. The underlying ideas are great but the thing is you are probably doing all of that. Well perhaps not TDD but mostly everything else.
And on that note, this book is basically a love letter to TDD which is not necessarily bad but be prepared that it's mentioned A LOT.
January 6, 2022
A well worth read for anyone in the software industry that have managed to grasp the basics of software development and now want to take it to the next level. But should also serve as a gentle reminder to highly experienced people on what really works to avoid being stressed out by massive technical debt, missed dead-lines, and long bug lists.
David Farley have a background as a software engineer and have made contributions in the field of continuous integration. He shares his expertise through various media such as YouTube, books, and by providing training courses.
The book aims to helps software professionals think about their work more effectively, manage it more successfully, and improve the quality of the code being developed.
The book is split into three main parts where the first is about learning. By learning is here meant how to be able to improve software development by learning what works and what does not. Having (fast) feedback loops. Experiment a lot but in a controlled way to be able deduce what helped. Do not assume anything without testing your assumptions. Benefits of working incrementally.
Second part is about how to reduce complexity. Working with modularity to be able to make changes and combine modules in new ways in future projects. Cohesion, try to keep things together that change for the same reason. Separation of concerns, the code, the by now classic example that a function should do one thing and do it well comes into play here. Information hiding and abstraction to be able to hide away all the gory details and see the big picture when needed. Strategies for minimizing the cost of coupling.
Third part is shorter and is a high level discussion on tools. Mainly pointers on how to achieve testability.
The main material is mixed up with short real world stories that complements and the more theoretical main discussions.
Farley comes across to me as he know what he is talking about both from a practical viewpoint and a more theoretical side. He have been working with software development himself for many years but he also makes multiple references to valid books and research showing that he has also done his homework by taking time to learn.
The material presented is in the book is maybe nothing ground breaking but it is presented in a good and clear way albeit sometimes at a very high level. There is however some deep dives into actual code snippets.
The "war stories" that breaks of the ordinary material regularly throughout the book complements the text very well and were both interesting as well as helping out to clarify the material.
All the software companies that I have worked at could greatly improve the quality and efficiency if managing to get everyone to understand and start following the concepts presented in the book. The same goes for me personally I can rarely be disciplined enough to work in the more structured way presented in the book even if it would help me greatly in the long run.
A downside about the book is that you can feel a bit like you are left hanging and wonder what to do next now. This is because the book is often written at a high level and lacks details. On the other hand so will this book in the way it is written be able to be relevant for a long time and might even in the future become one of the classic software development books.
David Farley have a background as a software engineer and have made contributions in the field of continuous integration. He shares his expertise through various media such as YouTube, books, and by providing training courses.
The book aims to helps software professionals think about their work more effectively, manage it more successfully, and improve the quality of the code being developed.
The book is split into three main parts where the first is about learning. By learning is here meant how to be able to improve software development by learning what works and what does not. Having (fast) feedback loops. Experiment a lot but in a controlled way to be able deduce what helped. Do not assume anything without testing your assumptions. Benefits of working incrementally.
Second part is about how to reduce complexity. Working with modularity to be able to make changes and combine modules in new ways in future projects. Cohesion, try to keep things together that change for the same reason. Separation of concerns, the code, the by now classic example that a function should do one thing and do it well comes into play here. Information hiding and abstraction to be able to hide away all the gory details and see the big picture when needed. Strategies for minimizing the cost of coupling.
Third part is shorter and is a high level discussion on tools. Mainly pointers on how to achieve testability.
The main material is mixed up with short real world stories that complements and the more theoretical main discussions.
Farley comes across to me as he know what he is talking about both from a practical viewpoint and a more theoretical side. He have been working with software development himself for many years but he also makes multiple references to valid books and research showing that he has also done his homework by taking time to learn.
The material presented is in the book is maybe nothing ground breaking but it is presented in a good and clear way albeit sometimes at a very high level. There is however some deep dives into actual code snippets.
The "war stories" that breaks of the ordinary material regularly throughout the book complements the text very well and were both interesting as well as helping out to clarify the material.
All the software companies that I have worked at could greatly improve the quality and efficiency if managing to get everyone to understand and start following the concepts presented in the book. The same goes for me personally I can rarely be disciplined enough to work in the more structured way presented in the book even if it would help me greatly in the long run.
A downside about the book is that you can feel a bit like you are left hanging and wonder what to do next now. This is because the book is often written at a high level and lacks details. On the other hand so will this book in the way it is written be able to be relevant for a long time and might even in the future become one of the classic software development books.
June 26, 2022
I think software engineers beginning their career, or have heard about what good software engineering is and want to know more, will find value in this book - especially part 3.
However, as someone with nearly a decade of experience I didn't find much here I didn't already understand or agree with. The first two parts were heavy on anecdote and digression (which was odd when Dave kept telling us the value of science) which was a bit of a struggle and I can't say I got the message - maybe I need to re-read those parts.
If you're an intermediate to senior engineer at a decent engineering company I would give this a pass.
The main thing I got was to add Accelerate and Dave's other book, Continuous Delivery, to my reading list.
However, as someone with nearly a decade of experience I didn't find much here I didn't already understand or agree with. The first two parts were heavy on anecdote and digression (which was odd when Dave kept telling us the value of science) which was a bit of a struggle and I can't say I got the message - maybe I need to re-read those parts.
If you're an intermediate to senior engineer at a decent engineering company I would give this a pass.
The main thing I got was to add Accelerate and Dave's other book, Continuous Delivery, to my reading list.
April 17, 2023
I have no idea why so many great engineers, who would never dream of writing code that is verbose, repetitive and convoluted, are quite comfortable writing books like that. This is one example. It could quite easily have been summarized as a couple of blog posts, none of the meaning would have been lost, in fact editing would have conveyed the few simple ideas at the heart of this book in a much clearer and more compelling way. It's very light on practical examples and many of the ideas are better explained in other books. If I wasn't already an experienced engineer, much of this would actually be hard to follow, largely because of how endlessly repetitive it is.
Displaying 1 - 30 of 134 reviews