Modern Software Engineering by David Farley
I recently finished reading Modern Software Engineering by David Farley. Here are my thoughts, key takeaways, and how I think these ideas apply to my work and the industry.
Cover image © David Farley / publisher. Source: Amazon
Summary
Time is tight these days between contract work and searching for a new job before my current contract ends, so this won't be a perfect summary. Still, I really loved this book and wanted to share some thoughts.
I discovered the book through Dave’s YouTube channel, which I found after months of watching videos related to software engineering. After watching several of his videos, I checked out the book on Amazon, read the preview, and was immediately hooked.
Key Takeaways
Software engineering vs "programming", or "the craft" analogy.
I really like the craft analogy—the idea of a long journey, apprenticing, and gradually moving up through the ranks. But Dave makes a great point: software engineering should be more of a scientific approach. The concept of "not knowing all the answers" at the start is extremely empowering. Treating the process as discovery and iteration aligns with how I’ve done my best, most engaging work: starting with a concept, breaking it down, proving out each piece, connecting them, and refining as I go.
Focus on the design and approach
Changes in languages, frameworks, or tools might give you some productivity boost, but it’s probably not the “10x” increase you’re hoping for. The real change comes from design and approach, which are generally agnostic to specific languages and frameworks.
Test Driven Development and the interconnectedness of it all
There was a lot of discussion around test driven development. I was exposed to TDD years ago, and whenever I’ve taken the time to slow down and work this way, it’s always been beneficial and empowering.
I find that:
- My code is fully tested.
- I don’t dread testing as a mandatory “chore” at the end of writing something new.
- I am confident my code does what it says it does.
- I can change my code and be very confident I have not broken anything with the refactor.
But I hadn’t realized the additional benefits it was giving me—guiding me toward a fundamentally better system design.
A test driven approach guides you toward architectures and solutions that demonstrate:
- Modularity
- Abstraction
- Separation of concerns
- (Appropriate) Coupling
- Cohesion
Each of these concepts reinforces the others.
Continuous Delivery
Dave describes working on teams that have adopted true Continuous Delivery. Code that’s checked in goes through quality gates, and if it passes, it’s ready for release. This doesn’t mean every commit is released to customers, but it could be—if all the parts are in place and there are enough features to ship.
I believe this is how companies that update their software constantly operate. This approach enforces a strong “definition of done” and lowers the friction of getting features to users. It may seem “extreme” to companies that do things differently, but if you take the time to do it right, there’s no better approach for empirically lowering time-to-market and defect rates.
Reflections
I’m hoping to do more personal projects soon and pick up where I left off with the ones I started this summer. I definitely want to incorporate these concepts more, and refactor what I’ve done to use them.
My current contract work is focused on proof of concepts and research. Being able to assemble even moderately complex systems so that you can demo new progress to your manager or colleagues each week would be extremely beneficial!