The science of software development

October 7, 2021

A quick reminder: Tomorrow at 17:00 CET (Europe) / 8:00 AM PT (Americas), I’ll be doing a free, live video Q&A session answering your DevOps technology questions. Space is limited! Register up now!


I want to talk about the science we use every day in software development.

I don’t mean “science” in the sense of “knowledge,” as when one says “Science says we should exercise.”

I also don’t mean “computer science” as in the topic of study.

I mean the actual scientific method, which I’ll simplify for the sake of discussion to: Observe, Hypothesize, Experiment, Analyze, Repeat.

In how many ways do you use the scientific method in your daily work?

  • If you’ve ever built an MVP (a real MVP, I mean), the sole purpose was testing a hypothesis about a product.
  • If you use Scrum, each sprint is one iteration of the scientific method (or at least it should be). Your team observes the current state, sets a goal (hypothesis), experiments to find a solution, then analyzes the results in a retrospective, before iterating again.
  • If you practice Behavior-Driven Development or Test-Driven Development, you’re using the scientific process on the story, or even function level.

Where else do you use the scientific method? Send me a message and let me know!


Related Content

Reader response to: The science of software development

"Debugging is the act of answering questions and then answering them. Not: guessing what the answer is."

"Agile" is not a noun

Even in the manifesto, the word "agile" is used as an adjective, not a noun. I think this clarifies the meaning significantly.

When to not be agile

What if you're in a business where you know all the requirements up front, you do not need to respond quickly to change?