Granted, I work on the hardware side of things, at an architect level, and my only programming work is supporting my own short term needs. On hardware projects,

Granted, I work on the hardware side of things, at an architect level, and my only programming work is supporting my own short term needs. On hardware projects, "we develop it, you test it" is a huge problem, because testing invariably becomes a bottleneck, and is deferred until dangerously late in the development process. Tested subsystems are substantially more valuable than untested ones. In my own IC work, related to my specific area of domain knowledge, I do not submit untested designs. Everything I design comes with a test process, which usually involves code that I write myself. My designs rarely come back to me. For this reason, I support TDD in principle, though I haven't learned enough about it to be great at it. "Don't interrupt the programmers" is a problem because they end up becoming isolated from the rest of the team, and have to work twice as hard to catch up when the hardware design gets thrown over the wall for them to deal with. The people who can handle interruptions become by default the ones who participate in the critical technical decisions.