A co-worker who is annoyed with the verbosity of our verilog simulations just asked me if I subscribed to the Dark Cockpit Theory. I immediately replied, "no." I've had this argument a number of times with other engineers and I have already decided that more information is better than less. I had to google "dark cockpit theory" later because I'd never heard of it referred to that. For me it has always been the UNIX "Rule of Silence". Same idea, I think.
Just to be clear, I do like the Rule of Silence when it's software that I trust isn't going to do weird things or silently hang. There isn't a lot of code that I trust that much, though, and if it's software I don't trust, I want to know what it's doing, or at least that it's doing something.
As I thought about this more, it's the same with people. When a person you trust is doing something for you, they can go do it without giving you any intermediate status reports. That's easier and more efficient for both of you. When someone you don't trust is working for you, you want to hear from them often, so you know they are staying on task and doing things right. Right?
The big argument about overly noisy simulations or software is that you can't find the important messages in all the noise. I just don't understand this argument when it's coming from fellow software engineers. Especially UNIX/Linux users. We read obtuse source code all day long, and we confidently use tools like grep or the search features of vim or emacs to help us. These same tools can search through program output. UNIX shells have built-in ways to redirect program output to files if you don't want to watch it all scroll by. If you really don't like it send it to /dev/null! Use the tools of the trade. Usually what people are complaining about is that the message they want to see isn't the only one being printed. Tough! You are a UNIX user, pipe the output through grep. Take 20 minutes and write a script to filter the output if you need. You write code for a living, you know how to do these things.