''I tentatively agree. A HeisenBug might have caused this in the first place e.g. due to arace condition that only happens when the threads involved behave 'unusual' because of the debugger stopping one of them for a time. And a HeisenBug might necessitate extra tools to be used to track this down (the 'MonkeyPatch' above). But nonetheless the XP way of using that would probably be to mock the logic in the threads. Probably there are not yet enough tests present to cover this.''

''This is how XP may gradually fail in the presence of multi threading. Concurrency is hard and this is not made easier by XP. You have to write more tests and this requires knowledge and discipline. In any case it wouldn't have been as easy as told above.''

XP makes concurrency very easy if you follow these steps:

* no PrematureConcurrency
* refactor towards an EventDriven object model by any means necessary
* get all your features working with simple ActionChunking
* debug and productize your features
* prove, with numbers, that threading will improve things - not make them worse
* if you can't prove that, you have a clean design so go with it
* if you need concurrency, trivially move your work loop into the thread, and pass all the tests.
* keep alive the tests that run the work loop in its synchronous incarnation
* soak-test the threading.

Note those steps emerge from DoSimpleThings - if you recognize how dreadfully complex a simple Thread call is. 

They don't make your code HeisenBug proof. However, those rules reproduce the standard design tutorials describing how to keep threads safe. It's all about the structure!

Next, if you have a HeisenBug, RevertDontDebug.