Do Software Developers Make Better Traders?

I've been wanting to dig into this question for quite some time, but have been busy with some visual EA development lately, so I've not posted this here until now.

I've worked with two MQL coders in the past and in each instance, there came a point in the relationship where it became clear to me that the MQL coder really did not have a wealth of trading experience, or more importantly, an understanding of what makes good Trade Logic. They were both excellent programmers, no doubt.

I probably worked with two individuals who if they were known, might be considered top notch MQL developers, with other programming languages under their respective belt as well. But, when it came down to understanding what I call the Theory of the Market, which is my starting point for developing any new Indicator design, they simply had no follow-through from a logical standpoint on how to get the indicator to reveal what was important about the underlying theory.

So, before I begin, I wanted to make it clear that this is not an attack on developers either in specific, or in general terms. This is just to air out the question of the perception that many people have with respect to Developers and their trading skill.

Some developers (especially those who have mastered MQL), don't ever come straight out and make the proclamation that they are consistently profitable traders. But, if you note their replies to non-programmers and non-developers, you detect a distinct aroma of headiness with respect to their capabilities as developers and how that 'may' translate into their capabilities as traders. I've been aware of this aroma of headiness for years now, and I'm always taken back by the insinuation and/or the implication. Though it is never really spoken by anyone, many coders imply in the tone of their posts, that in order to become a successful and consistent trader, one must learn the programming language of some trading platform, or at least be somewhat familiar with it - whatever that means.

There is a clear distinction between Software Programming and Trade Logic. Can they be related? Of course, they can and often times are related, but that which drives any software code related to trading, must come from some source of trade logic. In other words, it is the Logic that drives the Code, and get the impression often times that some programmers forget this fact.

So, for example, as a successful and consistent trader, you find that you would like to do something using a platform's trading language, but you find that doing so, is not possible unless you know the source code underlying what it is you want to accomplish, and you express your thoughts that in your mind, you believe the entire process for accomplishing what you need should be much more easily done within the trading platform itself without coding; you are told that you might be approaching the entire idea with the wrong attitude and that you either learn the platform's source code, or do something else. I've often wondered whether or not that particular developer, understood what it means to be a consistently successful long-term trader.

Trade Logic, is the idea that turns a market condition into a profitable position, by executing a trade based upon careful historical research, design, development, testing, analysis and proofing, of a theoretical principle that contains a high enough degree of probability towards an expected outcome. Software development, is not even remotely close to being the same cerebral process.

At the core, trade logic implies a highly engaged inter-communications process involving both left and right hemispheres of the brain, including an extremely high degree of engagement and coordination with the Visual Cortex. Anyone that has ever conceived and designed their own unique set of indicators, can and will attest to this high level of coordination between these three centers of the brain. The level and depth of the coordination between the three, when conceiving and/or giving birth to a brand new indicator design and/or type/classification, can be all consuming at times - as it take every ounce of intellectual horsepower that one can muster, to bring into existence that which never before existed. And, that's just the Indicator design level. Actually, integrating a set of new indicators together, to form a synergy of output that yields a high degree of probability for accurately describing predicted market behavior, is another world unto itself - again, far removed from writing software code based on a per-selected script of specifications.

In other words, conceiving, developing, designing, researching, testing, analyzing and then optimizing a high probability, fully integrated trading system that accurately performs the task of projecting market behavior before it happens and to a high degree of probability, and within any market condition (bull, bear, flat and transition), is a rather daunting task for anyone, regardless of their former background.

Yet, I continually hear the inference that somehow, being a software programmer is going to make me a better trader, than if I were not a software developer. Of course, my personal experience in working with a couple software developers as revealed the exact opposite. I have found that some coders get so locked into the various rules of development, that they don't demonstrate the creative bandwidth to see beyond the obvious, such that they are able to develop their own indicator and/or theory of the market designs. So, they end up taking an already existing indicator design and re-writing the underlying code, such that it looks different and behaves in a slightly different way - but the underlying theory of the market remains the same.

So, let me open up the floor on this question, because I think it is a very interesting question, indeed. We see a ton of EAs out there for Sale. Obviously, non-programmers and non-developers are not the source of these EAs for the most part. Yet, we continually find that in almost all of the cases, some EAs run fine during certain market conditions - for example, a Bullish EA design works great in a Bullish market. However, when that market changes its type, the EAs performances drops considerably. Or, a Flat Market EA works great in a channeling market, but once the market goes vertical, the EA breaks down. We see this over and over again, all across the net.

So, what's the real deal? Do developers make better traders, and if so, what it is about software writing skills that makes one a better trader under all market conditions? Why has Silicone Valley, not replaced Wall Street, or the City in London, as the prime source of "traders" world wide?

Just curious.

iD

If it dint...it will

You can't program an EA or any other software to think, only humans can really do that.


I'm a software developer, which basically means problem solver, that is what I do, creativity / imagination not really what computer people do.

There are lots of good points made. I just want to touch on one regarding the nature of how mql is structured compared to other languges. Perhaps even more so than general C or C++ (and like SQL), MQL is procedural..i.e. top down. I'm no mql expert, but I do have a good general development background. Within the last few years most languages have gone from the top down paradigm, to object oriented. Object orientation seems to be a lot better for defining default and catch all type of logic, mainly due to it seeing data structures and the behaviors that act on the structures as 2 totally separate entities. For procedural languages, behaviors are more explicitly programmed. Therefore, if the developer is unaware of a particular set of circumstances, it may be hard to explicitly define the scope of the coding.

One option if you want to keep using metatrader is to use DLL calls to trigger other transactions, like how we run R statistical calculations by sending metatrader quote data to R on the 7bit thread. There are examples of connecting to matlab as well. We know wall street quants have used these tools to drive HFT on equities markets, it remains to be seen how far it can penetrate fx...but of course we know its possible.

FYI:

CEP may be a better platform for what you are trying to do:

http://en.wikipedia.org/wiki/Complex_event_processing
http://www.e-forex.net/Files/cep_technology/2.pdf
http://www.marketcetera.com/site/

I'm also taking a look at fastbrokers platform pathfinder, it can dynamically route orders across ECN's and all kinds of other neat stuff. I would say its development language is CEP based, the code is very non-verbose (few commands, lots of work). Send me a PM if you go with fastbrokers, I'm wanting to setup an HFT algo with them as soon as I can figure out one that works

Developers do not make better traders. At least not by themselves.

Trade logic is still needed as you said. The bot that is programmed is only as good as the strategy they base it on. If that strategy is flawed to begin with, no amount of coding experience will help you make money.

Which is why there is usually an old fashion "trader" and the programmers working in a team. The trader will provide the trade logic and the programmers will code it.

This is discussed before somewhere in the old threads of ff. The reason why so many bots fail is because of the trade logic. And to add on, mashing 4 or 5 robots at the same time tends to be a bad idea. Unless you have 4 or 5 proven trade logics - in which case, you don't really need to mash robots together to begin with.

Your better off building a selection of bot's for different market conditions then picking the 1 to use at the time, EA's can't really see market conditions.

Market generally goes in cycles of 3 to 4 months, so if you run all the EA's in back test say 5 - 10 days back then trade the most profitable 1 if there is a profitable 1 take the cash while you can and when you get 5 - 10 days worth of losers repeat the process, you won't spot the market change initially you'll just have to accept giving some back.

Ofcourse if the market changes to soon after you switch EA's then you won't make enough to cover the wrong EA periods.


If you could make it automatically back test and automatically pick the right EA for that pair there and then, that might work also, if you wanted totally hands free.

* I'm not helping code above, sorry, I do enough coding in my day job.

have you been in a magnet resonance tomography while developing your indicators? If not, then you have no way of knowing which parts of the brain are to which degree engaging with each other when developing an indicator.

I personally think that a good ea is better than the average profitable trader. But an amazing trader will be better than any ea.

lol I agree certain parts of that post has been taken a tad too far. But his general concept of a trade logic is sound - basically saying that trade logic is derived from experience or tested over time.

And that is the crux of this discussion. Trade logic is needed and it needs to be profitable before you can translate it into a robot. Without these conditions, whatever you program will ultimately fail.

So really, pure programmers will not beat the market.

But I'm willing to say that programmers who end up learning how to trade or codes a robot based on a successful trader will probably end up better than most. Simply because he understands the concepts of a winning trade. It is the exposure to good trade logic that produces the winner.

To whatever extent banging out software for 25 years has hardened my perfectionist tendencies, it has hindered my progress as a trader. I have slowly come to realize that trading is an art, and that the pursuit of a holy grail through perfecting a mathematical algorithm was — at least for me — a futile exercise. But perhaps that's because my knowledge of math is simply not good enough.

Throughout my trading journey, perfectionism has retarded my progress more than fear or greed. (Unless, of course, we regard perfectionism itself as a type of fear: the fear of making mistakes). Instead of persevering with what could well have been perfectly good ideas and strategies, I've discarded them, in the hope of finding better ones.

Regarding vended EAs: they hardly represent the pinnacle of forex software development. Many of them are not even designed to be profitable; they are created merely to maximize sales income for their distributor. Given the laziness, greed, and lack of discernment of potential buyers, there is no real incentive to produce a quality product.

EAs execute flawlessly and emotionlessly, hence those that fail do so simply because they are not intelligent enough. The failure may be due to lack of trading knowledge on the part of the developer, but the problem is further exacerbated by the fact that (at least as far as I'm aware) the most robust trading methods are discretionary and/or 'visual', and are consequently difficult to nail down in precise mathematical terms. For example, (after 5 years of study) I can look at a chart, and quickly gauge the 'quality' of any support or resistance. But, despite having coded what I would consider to be some reasonably complex algos, I have all but given up attempting to code my own trading method. The automated functions that I run serve their purpose, but only because they allow for plenty of manual overrides.

To any programmer who has written a stand-alone, profitable EA — and I mean one that has proven itself to be consistently profitable, over several hundred trades, and many years of changing markets — you have my utmost admiration.

David

That is VERY true. Yet many of the systems threads work the other way around. Somebody presents a largely untested idea, and then asks a programmer to write an EA to backest it, to see if it's profitable.

Hanover,

You've made some very important points here: especially the part in bold. This one stands out to me...

Throughout my trading journey, perfectionism has retarded my progress more than fear or greed. (Unless, of course, we regard perfectionism itself as a type of fear: the fear of making mistakes).

Here's another:

The automated functions that I run serve their purpose, but only because they allow for plenty of manual overrides.

Read your post a few times...will read it some more.

Thanks.

FX4

The simple answer is no, simply because programmers, usually, are not traders.
People who actually have the intersection of all the skills required are few and far between. The same argument holds with quants, if all it took to trade were quantitative skills, then there would be a lot of rich professors. Quants in most shops are kept far away from the money.

based on my casual definition of "Software Developers", i would say they would at least have a distinct advantage over the average joe...... and if the common 95% number is correct, they really don't need much to be better......

my definition of "Software Developers" would include all but a few of the people in my vouched for list......

//----

course there is no shortage of professional programers , even on this forum, that admit not being dissatisfied with their results......

but still, all things considered, in the back of my mind, i feel they have an advantage over me.....h

Interesting post. My journey has been completely opposite. Manual / discretionary trading was for me like going into a mine-field blind-folded. I just had no idea what worked and what doesn't.

Testing out my ideas through a backtester has allowed me to finally figure out what works in the markets. Moving away from manual trading to backtesting and then automating the backtests has been the best decision in my trading career.

Hey,

This documentary was about noobs offered a role as traders as an experiment, there was quite a mix of characters including an older gentleman, a computer geek programmer...ahahahhhh

One word fail...lol

Start at episode one, you'll be hooked, check it out...



Cheers

Dane

LOL! That was hilarious.

I think it highlights one of the distinctions that I made in my original post: All Algo trading is machine trading, but not all machine trading is HFT trading. Any automated trading process, no matter how elaborate, is a machine trading process. However, not all machine trading processes are High Frequency Trading processes.

Even so, are the computer programmers typically the people coming up with the trade logic that ends up converting mediocre results, into consistently profitable trading patterns?

But, doesn't that all depend on how you define what "thinking" means?


Is a software developer a problem solver, or a specifications executor? Where does the genesis for an idea begin - in the mind of the developer, or in the mind of the one who created the idea (assuming the one who created the idea, was not also the developer)?

Again, what's up with Silicon Valley. Why have they not surpassed Wall Street as the well known Mecca for all things Automated Trading?

That was a very interesting video. I had heard about the MT4 Dealer Plug-In before, but had not heard that someone had produced an MT4 monitor for detecting such things as spread widening that was out of normal spread patterns. I'll have to take a closer look at that - thanks.

Regarding HFT in FX. It can truly be done by those trading retail accounts, IMO. HFT, by definition requires that practitioners these days have an edge when it comes to data-feed latency. HFT transactions have become so quick, that I don't think it fair to conclude anymore that they even use the same data feeds the rest of the market uses - in fact, that cannot be the case at all.

The whole thing is legitimized when the Exchanges cut deals and make special use data available for HFT distribution hubs. It definitely seems like an Inside Game at this point in history.

Even though this video is a sales tool, it does a good job of explaining in lay terms, what HFT is and what it is not. It also helps to make it clear that getting to true HFT in Forex (retail) would be virtually impossible. This goes back to my other point that, not all machine trading is HFT trading, even though it might be Algo trading.

I would agree with everything you stated more or less, but would also take a different track on using a Multi-Bot approach.

My entire trading system is too complex for MQL to handle, for a number of good reasons. So, I've recently begun taking some key components from that trading system and seeing if they can work together using MQL and MT4, so that I could have some degrees of automated freedom.

But, even using just a few component from the larger system, has caused me to develop a multi-bot approach, where I end up building and integrating more than one into a single EA, with each EA generating its own trade signal. Of course, the key is figuring out when to suppress one signal and when to allow the other signal to control trade execution. I'm doing this with a Visual EA development tool, but I'm pushing it to the limit of what it is capable of doing. Everything I use is based on iCustoms, so its not like I can pull something down off the shelf that everybody else uses, and slap something together - that just won't work.

So, I agree about the need for sound trade logic, but I have a different take on whether or not an Integrated Multi-Bot scenario works. In fact, for other reasons, I'm contemplating the use of a Mult-Account/Multi-Bot System. Essentially, I would break the system into as many Bots as there were trade signals being generated by the whole, then place each Bot into its own account - dividing the total Equity Available by the number to trade signals.

It would be a form of Load Balancing the entire trading system, across multiple account and possibly across multiple platforms. Of course, I'd have to account for the differential in Slippage and Spreads at Execution, across each account, or across each platform. This also effectively deals with the no hedging rule.


Or, integrate them into a single EA and code the suppression of one over the other when the market conditions warrant it. I'm experimenting with that now.

I'm a system developer, so I might not come up with the requirement, I will create the system which handles the requirement so I technically have to solve the problem, which sometimes involves changing the way the company does it to streamline, they love that

Bring back the day of writing C64 games in my bedroom, good times!!