This is one of the best modern books on software engineering. The author's take on the empirical process of software engineering is a descaling operation on modern middle management "shm-agile".

In all honesty, this is one of the best books on software engineering, albeit a modern explication on the "No Silver Bullet" paper. Experienced engineers will find all of our suspicions confirmed: software is empirical not prescriptive, all software is deployment, all software is testability. In other words, Golang. But at least we have a faithful book to point at for the non-believers.

This is a must have book for software engineers. The part on engineering philosophy is a must for every engineer in my opinion. So why the 4 stars?let me explain my reasoning. The ideas in the book are important, but the presentation is still raw and underdeveloped. The ideas are intertwined making the text a hard read. For such a short book, I found that it took me a surprisingly long time to read. I hope that the author will treat this book in the same manner we should treat our software. With future, better and improved editions and with better clarity and separation of concerns between the topics. I do recommend that you buy and read this book. But like software, it can be improved.

Recently, I finished reading this great book by Dave Farley. It immediately was added to my "zero B.S. readings", along with Team Topologies and a few others. Those books I would take to a desert island if someone asked me to build up a software facility from zero. :)

What I really liked of the book is that it retakes the often discussed concept of software "engineering" and refines it to suit today's needs. I always felt we need an "engineering approach", but after the (gone) CMMI days, the term was always used more as a synonym to development rather than something to describe a professional, disciplined way to produce better software. I feel Dave's book puts back engineering into development, but with a very pragmatic and realistic approach, derived from actual experience.

When reading it, I felt a similar sensation to that I felt when I read Steve McConnell's Code Complete and Rapid Development, many years ago. Though very different books, I think Dave's also has that "handbook" nature. A book that you read once, but come back very often to look for ideas, concepts, etc. I hope Dave does not mind about my comparison.

Thanks Dave!

About 1/2 way through Dave Farley’s book at this point. I had an item in my ready column related to improving the performance of a query that is core to my new product. After reading the chapter on #empiricism and #experimentation I sat down this morning and set up an experiment with code that generated clear measures as a baseline. Then I set about #refactoring and ensuring I wasn’t more than a few undos from green tests. As I progressed I continued to compare my new measures.

After about 2 1/2 - 3 hours of refactoring I had achieved a 15x improvement and the queries are now “fast enough” to please my future customers. I was planning on doing this work anyways, but I think that what I had just read the night before pushed me towards a very disciplined, more scientific approach. I doubt that with a looser approach that I would have achieved that much improvement in such a short time.

I was prepared to #git reset and toss the work. I had no presupposition that it would be successful. It turned out to be completely worthwhile and an improvement to the codebase, to boot.

There is a difference between #development and #engineering.

Thanks, Dave.

#softwareengineering #softwaredevelopment #science #engineering

I really like Dave Farley, the author of this book and host of the Continuous Delivery channel. His treatment of software engineering from a true engineering perspective was eye opening to me. I've been an developer for years and years, but had never thought of it directly in that manner.

You won't read it in one sitting - the subject matter is perfect for skipping around to different chapters, depending on what you're currently working on or what topics pique your interest. Great book!

He says the same things over and over again but in different chapters. Very little code shown. Though anyone can gain some value, it seems to be more for a larger team. I got the big picture but very few practical examples.

I agree with most things he says. It is easy for someone to say what to do. But how to do it? Someone needs to write a book on how to find a job/company that does all those things he suggests.

When Dave Farley speaks or writes I pay attention. The CD book blew me away in 2010. This book doesn't add many new concepts or ideas to the discussion of what good software engineering looks like. But that's ok. It pulls a lot of apparently disparate things together at various levels of detail and helps you see how they relate to one another. It takes some positions that I don't necessarily agree with but any book worth reading should challenge your thinking. For example, it pushes TDD hard. I'm sorry, but the experience of many (I'd say most) is that (new of modified) tests being accompanied by a change during any checkin is more important than how you achieve that outcome. I tire when people suggest that TDD is the only way to do that. My point here is an illustration of outcome mattering more than mechanism, ironically covered in the last chapter of the book. That said, the book is loaded with sound advice, backed by experience that few people can match. Definitely worth a read.

Even if the concepts presented on managing complexity were familiar, I really enjoyed how everything was linked together to bring the focus on the process of software engineering .

amazing book !

I’ve been involved in building various kinds of software for nearly 20 years now (the book describes this as engineering, rather than building), and this book describes very well of what we should aim to when building software and this very much matches my personal perception of that. The book covers very fundamental subjects, yet it is really easy to read. We should not really treat ideas described in this book as dogma, but I believe that every software engineer, software developer, programmer or whatever they call themselves should read this book.

Describes many important concepts, and makes clear why those concepts matter.

Such concepts are incrementalism, feedback, separation of concerns, abstraction, ...

Some technical concepts are explained somewhere else in more depth, but I think that's fine: The book provides a good overview.

I loved this book, from start to end. All topics were well founded with a good amount of good examples. I understand that people expect more practical examples with real scenarios, but as stated by David, the book is not a recipe to achieve quality, but a foundation based on ingredients that are likely to lead your development to success. The examples given were simple, to illustrate and have a starting point to describe an idea. It's not only about coding my fellow friends, it's much more.

A collection of interesting approaches and insights on how to become or remain a modern software engineer.