A friend asked me to summarize what I believe about software in five points or less. I previously described those points. Here is where each of those beliefs originates from.
Understand the Problem
Understand the Problem originally stems from Fred Brooks and his writings on essence vs accident. Namely No Silver Bullets and Design of Design. The idea was given greater form by What is Software Design, Domain-Driven Design and the Software Engineering Body of Knowledge (SWEBOK). SWEBOK is particularly responsible for the view of software as a series of translations of the same problem definition. Stop Corrupting Yourself improved how I apply this belief to tests.
Stable, Incremental, Additive
Stable, Incremental, Additive also stems from Fred Brook and his book Design of Design. He uses the design tree to describe incremental work cycles, which I’ve also written about. This idea has been reinforced often in my career, but I’d say Refactoring and Code That Fits in Your Head are some of the best demonstrations. Refactoring helped me understand true CI/CD and how Stable, Incremental, Additive can be practically maximized through the whole software lifecycle.
Self-Documenting Code
I first encountered Self-Documenting Code in Code Complete and Pragmatic Programmer. The idea was refined by Domain-Driven Design, Domain Modeling Made Functional, and many other sources through out my career.
Camping Rule
This belief stretches back a long ways. I’m not quite sure of the origin. I first encountered a name for it in Refactoring.
Tighten the Net
I’ve valued automated testing since the absence of it sunk the first professional project I worked on. Tightening the Net itself stems from Pragmatic Programmer. Reflecting requirements through the test suite stems from Stop Corrupting Yourself, which triggered a major reshaping of my testing practices.