12 Quotes

Any design that is hard to test is crap. Pure crap. Why? Because if it’s hard to test, you aren’t going to test it well enough. And if you don’t test it well enough, it’s not going to work when you need it to work. And if it doesn’t work when you need it to work the design is crap.

– Robert C. Martin, blog

Being in too much of a hurry can hurt. Don’t ignore a crash when it happens; track it down right away, since it may not happen again until it’s too late. A famous example occurred on the Mars Pathfinder mission. After the flawless landing in July 1997 the spacecraft’s computers tended to reset once a day or so, and the engineers were baffled. Once they tracked down the problem, they realized that they had seen that problem before. During pre-launch tests the resets had occurred, but had been ignored because the engineers were working on unrelated problems. So they were forced to deal with the problem later when the machine was tens of millions of miles away and much harder to fix.

– “Debug it now, not later”: The Practice of Programming, https://www.cs.princeton.edu/~bwk/tpop.webpage/debugging.html

Sometimes a pattern in the numerology of failing examples gives a clue that focuses the search. We found some spelling mistakes in a newly written section of this book, where occasional letters had simply disappeared. This was mystifying. The text had been created by cutting and pasting from another file, so it seemed possible that something was wrong with the cut or paste commands in the text editor. But where to start looking for the problem? For clues we looked at the data, and noticed that the missing characters seemed uniformly distributed through the text. We measured the intervals and found that the distance between dropped characters was always 1023 bytes, a suspiciously non-random value. A search through the editor source code for numbers near 1024 found a couple of candidates. One of those was in new code, so we examined that first, and the bug was easy to spot, a classic off-by-one error where a null byte overwrote the last character in a 1024-byte buffer.

– “Study the numerology of failures”, The Practice of Programming, https://www.cs.princeton.edu/~bwk/tpop.webpage/debugging.html

Contemporary software engineering still has a lot to learn from the 1970s. As we’re in such a fast-moving field, we often have a tendency of dismissing older ideas as irrelevant—and consequently, we end up having to learn the same lessons over and over again, the hard way. Although computers have become faster, data has grown bigger, and requirements have become more complex, many old ideas are actually still highly relevant today.

– Martin Kleppmann - Making Sense of Stream Processing, from Confluent

TDD is an awareness of the gap between decision and feedback during programming, and control over that gap.

– Kent Beck, “TDD By Example”

When a measure becomes a target, it ceases to be a good measure.

– Charles Goodhart, https://github.com/dwmkerr/hacker-laws

12.1 Why not TDD

As advised, I have started with writing a test.

That test is taking forever to complete, though, and I don’t see a way to make it run any faster.

It’s in fact so slow I would’ve implemented the feature long ago, but it’s still running to complete the first iteration.

That whole TDD approach thus looks like a pure waste of time.