#begin
Chapter 8 is about adopting an experimental mindset in software development. David argues that we should stop relying on opinions or authority and instead base decisions on evidence. If you want to know whether a programming language is better for a specific job, don’t debate it — run a small experiment and measure what matters.
Evidence over Opinions
Most technical discussions are driven by personal preference. Farley pushes for a different approach: try things out, gather data, and let the results guide the decision. Small, low‑risk experiments give you real insight into how a tool or technique behaves in your context.
Feedback as a Core Mechanism
Experiments only work if you can learn from them. That means fast, reliable feedback. Automated tests, monitoring, and user interactions all play a role here. The shorter the feedback loop, the faster you can adjust and improve.
Start with a Clear Hypothesis
Every experiment needs a hypothesis — something specific you want to validate. In software, that might be:
-
“This architecture will scale better under load.”
-
“This caching strategy will reduce latency.”
-
“This refactoring will improve performance.”
A hypothesis should be measurable. If you can’t measure it, you can’t learn from it.
Measure the Right Things
Bad metrics lead to bad behavior. Farley gives an example of a team rewarded for increasing test coverage. Developers responded by writing tests with no assertions. Coverage went up, quality didn’t.
The real metric should have been stability.
Good experiments depend on meaningful measurements. Focus on outcomes, not vanity metrics.
Control Your Variables
To trust your results, you need to control the environment. If you’re testing a caching strategy while server load is all over the place, your data is useless. Control what you can — environment, input data, dependencies, hardware — so you know what actually caused the change.
Automated Tests as Experiments
Farley frames automated tests as micro‑experiments. Each test encodes a hypothesis about how the system should behave. Running the test tells you whether that hypothesis still holds. This is why automated testing is so important: it gives you constant, objective feedback.
Software Isn’t Physics, but Experimentation Still Works
Software doesn’t have the precision of physics, but that doesn’t make experimentation less valuable. Other sciences deal with messy variables too, and they still rely on systematic experimentation to learn. Software teams can do the same.
Takeaway
Being experimental means building software based on evidence instead of assumptions. It reduces risk, improves quality, and helps teams make better decisions. It’s a mindset shift: stop guessing, start testing.
#end
01010010 01110101 01100010 01100101 01101110
Recent Comments