Ask The Computer

From PairProgramming: Ask The Computer. Don't reason about what will happen if you do X. Do X and see what happens. Send the message and see what it does.

See also some discussion on ExtremeAdaExperiment.

This scares me: at least occasionally it is an anti-pattern. When you send a message, you find out what happens this time. You get a low-level, non-abstract answer. If you rely on it, you may create code which is more tightly-coupled than it need be. You are writing to an implementation instead of the specification.

For example, if you want to know the order in which C++ evaluates function arguments, you could write a short program to test it. The answer you get will be specific to your compiler; in fact, the evaluation order is unspecified and different compilers can and do use different orders.

Similarly, you should not rely on specific sequences of Windows messages, because they can change between releases of the operating system. Again with 3rd party libraries.

The original context was ExtremeProgrammer(s) PairProgramming, presumably investigating in-house code. Think about how to write UnitTests to verify your knowledge. -- DaveHarris

UnitTests have the drawback of only testing the things that you think of. Likewise, a manual may be vendor specific as well. Since there are all sorts of sources of information and they all have levels of context dependence and accuracy, I use them all and allow my judgment and mental inconsistency detection operate at its fullest. Fewer information sources implies less chance of finding problems. Use every tool liberally, including the compiler.

Side note. The ExtremeWay presents direct "truths" that have various shades of applicability in various contexts. My MetaHeuristic is to use everything precisely when I think it is applicable. I don't see any simple universal directives that can not be broken to an advantage periodically. -- MichaelFeathers

That's why patterns emphasis context. It is not so much the rules being broken as the contexts being refined. -- DaveHarris

This may degenerate into TrialAndErrorProgramming.

I actually see this as a direct extension of RefactorAggressively -- if your problem is atomic enough, don't overthink the problem, just make the change and see what happens -- because your unit tests support you, you can RefactorAggressively if the result is incorrect. -- NickWiggill?