Quote from naifwonder:
I think retail trading platforms are ideal for certain types of projects. For that niche, these platforms are great at what they do, and for the most part, they are reliable within reasonable limits. I do not think retail platform developers churn out unreliable products. They do not have enoough control the hardware that they run on to be configured for the level of growth and reliability that would be expected of a more custom tailored solution. I do not see these retail platforms as targeting this more advanced user-base (advanced as in programmatically speaking - do not turn this into a debate about advanced in terms of trading knowledge). As such, it would be like blasting Toyota for under performing in an Indy 500 race. I think this distinguished is very easy to forget, and in some sense, tempting to make. I must admit, in cases where a retail platform was the ideal solution, I have had some pleasant experiences. There were certainly pros and cons, but not enough to turn me away from them completely
I am noticing some conversation here regarding the robustness of software: The ability of the custom platform to handle future ideas, new brokers, data feeds, etc. A well-built platform uses abstraction layers when it is possible to account for these things. For example, instead of simply calling a broker's specific code to get new bar data, there might be a custom function called getBarData() which calls the broker function, converts into a standardized format, then returns the bar data. So, if the developer would want to change the data feed api, they need only modify the inner workings of that function, and there would be no need to touch the code that depends on the abstraction layer. I think most programmers that know what they are doing tend to lean towards abstraction methodology where time and performance-requirements allow it - not just in trading platform development, but across any project where it is a reasonably desirable trait of the product.