Clever! And I do think that if we think of debugging as scientific experiments than that will improve our debugging. But if debugging is science, isn't all engineering science? It's not like the process of testing, identifying problems, and fixing them is unique to software engineering vs. other types.
Debugging other engineered systems is clearly just as much a science as debugging software. But there are other aspects of engineering that don't seem like science to me, like design and optimization.
Optimization most definitely is science - if done right, anyhow. You conduct observations (benchmarks) and form a hypothesis about what will improve speed/memory usage. You make the changes and conduct experiments to see if your hypothesis was correct. You draw conclusions based on the results and if your hypothesis was wrong, you change your hypothesis and try again.
Is optimization not science?
Edit: But yeah, design IMO will always be art as much as science.
This is a nice piece about debugging in the light of scientific methods (and vice versa). One detail, though:
The idea goes back to Francis Bacon, who, using modern CS terminology three hundred years ahead of time, called it a "conditional inductive tree".
This is an anachronism. There's no way Bacon or anybody else used the phrase "conditional inductive tree" in 17th century English. Bacon may have anticipated the idea, but the phrase itself, and that way of formulating it, are modern constructs.
Edit: by "that way of formulating it" I mean the idea of a conditional tree with branches as alternatives. It would be interesting to know the origins of the logical tree metaphor and how it evolved as part of logic/CS.
Oops, you're right. I misunderstood Platt to be quoting Bacon where he wasn't, and didn't check up on it when I skimmed The New Organon. I'll update to point out the mistake.
