book

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

by David Farley

December 2021

Intermediate to advanced

256 pages

7h 25m

English

Addison-Wesley Professional

Read now

Unlock full access

Engineering—The Practical Application of ScienceWhat Is Software Engineering?Reclaiming “Software Engineering”How to Make ProgressThe Birth of Software EngineeringShifting the ParadigmSummary
Production Is Not Our ProblemDesign Engineering, Not Production EngineeringA Working Definition of EngineeringEngineering != CodeWhy Does Engineering Matter?The Limits of “Craft”Precision and ScalabilityManaging ComplexityRepeatability and Accuracy of MeasurementEngineering, Creativity, and CraftWhy What We Do Is Not Software EngineeringTrade-OffsThe Illusion of ProgressThe Journey from Craft to EngineeringCraft Is Not EnoughTime for a Rethink?Summary
An Industry of Change?The Importance of MeasurementApplying Stability and ThroughputThe Foundations of a Software Engineering DisciplineExperts at LearningExperts at Managing ComplexitySummary
Practical Advantages of Working IterativelyIteration as a Defensive Design StrategyThe Lure of the PlanPracticalities of Working IterativelySummary
A Practical Example of the Importance of FeedbackFeedback in CodingFeedback in IntegrationFeedback in DesignFeedback in ArchitecturePrefer Early FeedbackFeedback in Product DesignFeedback in Organization and CultureSummary
Importance of ModularityOrganizational IncrementalismTools of IncrementalismLimiting the Impact of ChangeIncremental DesignSummary
Grounded in RealitySeparating Empirical from Experimental“I Know That Bug!”Avoiding Self-DeceptionInventing a Reality to Suit Our ArgumentGuided by RealitySummary
What Does “Being Experimental” Mean?FeedbackHypothesisMeasurementControlling the VariablesAutomated Testing as ExperimentsPutting the Experimental Results of Testing into ContextScope of an ExperimentSummary
Hallmarks of ModularityUndervaluing the Importance of Good DesignThe Importance of TestabilityDesigning for Testability Improves ModularityServices and ModularityDeployability and ModularityModularity at Different ScalesModularity in Human SystemsSummary
Modularity and Cohesion: Fundamentals of DesignA Basic Reduction in CohesionContext MattersHigh-Performance SoftwareLink to CouplingDriving High Cohesion with TDDHow to Achieve Cohesive SoftwareCosts of Poor CohesionCohesion in Human SystemsSummary
Dependency InjectionSeparating Essential and Accidental ComplexityImportance of DDDTestabilityPorts & AdaptersWhen to Adopt Ports & AdaptersWhat Is an API?Using TDD to Drive Separation of ConcernsSummary
Abstraction or Information HidingWhat Causes “Big Balls of Mud”?Organizational and Cultural ProblemsTechnical Problems and Problems of DesignFear of Over-EngineeringImproving Abstraction Through TestingPower of AbstractionLeaky AbstractionsPicking Appropriate AbstractionsAbstractions from the Problem DomainAbstract Accidental ComplexityIsolate Third-Party Systems and CodeAlways Prefer to Hide InformationSummary
Cost of CouplingScaling UpMicroservicesDecoupling May Mean More CodeLoose Coupling Isn’t the Only Kind That MattersPrefer Loose CouplingHow Does This Differ from Separation of Concerns?DRY Is Too SimplisticAsync as a Tool for Loose CouplingDesigning for Loose CouplingLoose Coupling in Human SystemsSummary
What Is Software Development?Testability as a ToolMeasurement PointsProblems with Achieving TestabilityHow to Improve TestabilityDeployabilitySpeedControlling the VariablesContinuous DeliveryGeneral Tools to Support EngineeringSummary
Engineering as a Human ProcessDigitally Disruptive OrganizationsOutcomes vs. MechanismsDurable and Generally ApplicableFoundations of an Engineering DisciplineSummary

Content preview from Modern Software Engineering: Doing What Works to Build Better Software Faster

14 The Tools of an Engineering Discipline

When I think about what a genuine engineering discipline for software should mean, I don’t think much in terms of specific tools, programming languages, processes, or diagramming techniques. Rather, I think of outcomes.

Any approach worth the name of software engineering must be built around our need to learn, to explore, and to experiment with ideas. Most importantly, if it doesn’t help us build better software faster, it is “fashion” rather than engineering. Engineering is the stuff that works; if it doesn’t work, we will change it until it does.

Although I may not be thinking of specific tools, that doesn’t mean there are none. This book is built on the idea that there are some intellectual “tools” ...