Modern Software Engineering: Doing What Works to Build Better Software Faster
Authors: David Farley
Publisher: Addison-Wesley Professional
Length: 2021
David Farley's approach to modern software engineering: learning through feedback, managing complexity, engineering principles, and Continuous Delivery as a discipline.
OriginalBrief
The essential idea
David Farley defines software engineering as the practical application of science to building software. In unpredictable environments, the primary optimization target is learning: work iteratively, seek feedback early, deliver incrementally, use empirical evidence, and treat decisions as experiments with stated hypotheses and success criteria.
The second target is manageable complexity. Modularity, cohesion, separation of concerns, information hiding, abstraction, and deliberate coupling keep change local and behavior understandable. Dependency injection, domain-driven design, ports and adapters, and test-driven development are examples of tools that support those boundaries rather than ends in themselves.
An engineering discipline needs testability, deployability, short change lead time, controlled variables, and Continuous Delivery. Speed without a testing and deployment foundation merely increases risk; the intended outcome is a codebase that stays integrated and potentially releasable through small, safe changes.
Decision lens
Key takeaways
Software engineering applies evidence and disciplined experimentation to practical software work.
Short feedback loops reduce the cost of correcting product, code, and architecture decisions.
Incremental changes limit blast radius and make learning attributable.
Modularity, cohesion, separation of concerns, and information hiding localize change.
Coupling must be designed deliberately because uncontrolled dependencies erode delivery speed.
Testability and deployability are prerequisites for sustainable release speed.
Continuous Delivery is an operating discipline, not a slogan or isolated tool.
Workplace experiment
Apply it at work
- 1
Audit feedback loops across pull requests, tests, observability, product signals, and post-release learning.
- 2
Define module boundaries and expected coupling before starting the next large initiative.
- 3
Move toward small trunk-based changes, automated checks, and safe release mechanisms.
- 4
Measure how quickly the team turns a hypothesis into evidence, not only how much output it ships.
Choose one action, define the observable effect, and keep the first test small enough to reverse.
Evidence
Sources and further reading
Primary source
Additional sources
Channel, aggregator, and commentary links confirm the work; they are not the primary source.