One thing that has bothered my lately is the enterprise focus in everything I read. This would be tolerable should it be explicitly stated, but often this is not the case, recommendation given in articles and books that I read often silently presume that the problem is in the enterprise realm. One example of this is found on Ingo Rammer's site:
"No matter which category your application belongs to, I heavily recommend NOT to use events, callbacks or client-side sponsors for networked applications. Yes, it's possible to use them. Yes, they might work after applying one or another workaround. The real trouble is that they are not exactly stable and don't really perform that nicely."
I have seen people follow this advice, and I was inclined to do so myself, although I did not fully understand why. It was not until I read his book, Advanced .NET Remoting, that it became obvious that this advice was for client-server scenarios with many (100+) clients. The problem with callbacks actually first arises when the number of client is so high that using synchronous callbacks to dispatching the event to all the clients takes too much time, or when using asynchronous callbacks, non-responsive clients start to burden the dispatching (both because of the connection timeout and the limited thread-pool). Having just a few clients, a couple of which are on separate machines, this does not apply to my scenario.
Some of us are just doing "simple" client-server applications that are not intended to scale to infinite number of clients :) We should not sacrifies (or downplay) a valid system attribute (e.g. responsiveness) or a simple design for a fictitious scalability requirement.
Another example is this dogma that web services is the only reasonable remoting mechanism, which I find myself reading about everywhere.