I really like the concept of Mechanical Sympathy (Hardware and software working together in harmony) pushed by Martin Thompson. Saying it quickly: you can't design very performant systems by simply relying on abstractions (that surround us in IT todays) and if you ignore the details of how TODAY's underlying things work.
Note: underlying things stands here both for software-level stuffs (java/.NET GC, native memory allocators, OS, ...), and hardware-level ones (today's CPU, memory cache lines, and kernell-passing network for instance).
But when I attended one of his session at the A-Team low latency summit in London last monday, I was even more enthousiast with one particular point he made during 3-4 minutes. That was something like:
Adopt a scientific and rational approach. Make a guess if you want, BUT confirm it by some real and serious experimentation. For instance: everybody told you that functional programming is the best option to make high performant and scalable systems? Test it by yourself, make the experience and measure it concretely. You will discover -like me- that all those memory copies (to ensure message passing immutability) have a cost. Ok, this cost should be acceptable for some scenarii, but you will be blocked at some point if you push further your objectives regarding performances. Don't listen what (most of the) people say: Test and measure by yourself! This is how we discovered what led us-after- to the Disruptor pattern.
I fully agree. Sometimes IT deals more with religion and dogma than concrete objectives and facts. You find some guys that blindly repeat (silly) statements that you can find on the street: "there is no such language for performance than this one", "there is no such platform/middleware than the...", "we should use this tool cause everybody...", etc.
Since this mouton de Panurge effect is not limited to the pure IT ayatollahs and may also affect all of us in some tiredness-distraction moments, I find the advise and the approach promoted by Martin Thompson very healthy.
Ok then: it's time to experiment and measure things more frequently in order to make our IT architectures and assertions more factual!
