Modern Software Engineering: Doing What Works to Build Better Software Faster

It turns out that books about best practices in software are always going to surprise me. They all speak about the same thing over and over again, and yet, these things are still not widely used.It’s important that business owners read that book too. They may understand that it’s not a number of developers that makes a difference but the skilled engineers that do.

I have always firmly believed that software engineering can and should be approached as, well, an engineering discipline. This book provides strong arguments that validate that belief and provides great practical advice on how to apply design engineering principles to software development. I highly recommend it to anyone involved in producing software, engineers and managers alike.

Todo perfecto con el tiempo de despacho, solo tuve un pequeño inconveniente con el empaque que venia con la tapa doblada, y como es blanda costo bastante hacer que no se notara tanto.

Passed along to my son who is university student in this subject.

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

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!

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.

This book is not very large, it is little over 200 pages but of pure wisdom, I don't buy many paper copies of software books, but this is one I like to read over and over.If you have ever worked in software development, you know that it's not easy to build and maintain reliable software systems. What Dave is saying just makes sense, it will help you better organize and focus on what is important. Every chapter has so many great advice that can guide you to become better software engineer.

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.

He compares engineering allot with software development. One has an hypothesis and tries to confirm or reject it via tests and experiments on the software stack on hand.Overall it is a great read.

I bought this book for myself after watching Dave Farley's YouTube channel. I've now bought a second copy for the office library and I'm suggesting that everyone in my development team reads it. For me, this is pure gold. Yes, you can get some of the info online - what can't you get online these days? - but this book consolidates many of the crucial principles of software design into a coherent guide to, hopefully, convince more developers that you can set yourself up for good (or at least better!) design and there is a tangible payoff if you do.If you do what I normally do and read the best, and the worst, reviews for a product before buying, you'll see comments about this book being repetitive, lacking actionable advice and lacking examples.Are the concepts in this book repeated - sometimes, yes. Ideas like separation of concerns and testability crop up throughout the book. There's a reason for that. The are fundamental to achieving good design (which is where this book is trying to take us) and if that means some of those points need to be hammered home a little bit harder, so be it.Lacking actionable advice? I don't get this criticism at all. The book is literally a guide on what you should strive to do to make better quality software. Make your designs testable. Achieve that with tools like TDD and CD for fast feedback. In the process you will achieve coherent design, separation of concerns and practice the correct degree of coupling. All of this is actionable - you many need to read more deeply into those concepts to apply them, but that's on the negative reviewer, not the author.Lacking examples? There isn't a LOT of code, but where it's helpful to illustrate a point more clearly there are examples, and I liked the fact that the author mixes up languages to show that none of this stuff is dependent upon the IDE, OS, or language du jour - these all come and go, but the good practice that this book advocates isn't a "fashionable" thing. It's just "good". My hunch is that this criticism comes from those with little actual experience, looking to be spoon fed the Fred Brooks' magic (silver) bullet. Hard luck guys - developing good quality software takes some effort, and that effort comes in the form of lots of learning, before you've writing your first lines of code.Having tried to be a better software engineer throughout my career, I've found that things don't always work out first time, or second, or third, but the more you practise good practice, the more effective it becomes. This book has reinforced the ideas I'm encouraging in our team and added clarity around areas that I had an intuitive feeling for, but not the experience to back up that feeling.This is a GREAT book. Buy it, read it, practise the techniques Dave Farley advocates. We all owe that to the profession.

Thank you Dave

A book of words, waffle, repetition and virtually zero concrete examples to illustrate the points. The underlying concepts are valuable, but are mostly well known already and explained better in other books. It's really frustrating that great engineers seem to make terrible authors.