Regarding programmers fixing latency:
The risk/reward for the programmer is totally wrong to expect any kind of optimal solution. Usually there are only a handful of people who even complain about the latency issue unless it is REALLY BAD, and most of those are complaining about things that are out of the broker's control ( ISP speed, Internet delays, etc. ).
The reward to the programmer for "fixing" any minimal latency at the brokerage is usually NOTHING. Most people won't notice any changes for the better. A few customers might notice an improvement, but these will be the same anal twits that will continue to complain about any remaining latency until there is ZERO latency whatever, which of course is impossible. So, basically they are never happy. Fast is never fast enough for them. The author of this thread is a clear example of this.
The risk to the programmer is substantial, as normally fixing any kind of latency is not a matter of making a few tweaks, but involves substantial design changes. This is because all of the "obvious fixes" for latency are usually done in the beginning. Once a product is mature, there is no "low-hanging fruit" remaining. Then, a comprehensive testing cycle. And all for what - there isn't any added revenue to be made by reducing a 3 ms latency at the brokerage to 2 ms, when the ISP is adding maybe 50-100 ms anyways. Any improvement will be lost in the noise.
When the "improvements" are rolled out, many times it breaks something else that was working well before. Then, you have THOUSANDS of real customers complaining and deciding to take business elsewhere all because of a few anal twits who are never satisfied. The programmer is now at risk of being demoted or fired if the problem is bad enough.
If you were a programmer, tell me WHY the hell you would ever want to bother with something like this.
I certainly can't find a good reason.
