良い取引システム設計に焦点を当てるこのビジネスを始めた. プロセスの大きい役割を担う明らかにプログラミング.
What most people don’t realize is that the programming experience can be quite challenging. When a project takes more time than expected, it tends to take far more time than the original estimate.
Programming is like Air Travel
Many of you travel regularly. Flying is pretty much a given when you travel any significant distance.
Programming is like air travel. Small problems compound into big ones.
How many times have you traveled and the flight arrived 5 hours early? The question is laughable. It doesn’t happen.
20 minutes early to the gates makes most frequent fliers ecstatic. They know that arriving early, even if only by a few minutes, is as good as it gets.
Performance does relate to the airline to some degree. Checking for maintenance problems prevents surprises 20 minutes before takeoff or, heaven forbid, in the air.
The crew arriving on time helps. The last time that I flew from Dulles to Dallas, the replacement crew arrived at the gate an hour late.
The last two times that I flew to Dublin, United Airlines lost my bags… 両方の時間. 時々, it really is 100% the airlines’ fault.
Force majeure
Those experiences aside, how many times do airlines goof up so badly that travelers arrive days late? Travelers do arrive with severe delays, but those circumstances are usually weather related. It’s outside of the airlines’ control.
I remember the volcano in Iceland that erupted a few years back. People were literally stuck in Europe for a week.
The sequester is a great example. In what’s certainly a willful choice to inflict pain on fliers, the FAA decided to furlough air traffic controllers at major airports.
Those airports are the same ones that I frequent. When I fly to Dublin on Tuesday and I’m potentially 4 hours behind schedule, I’ll be angry. しかし, I’ll also know to direct that anger at Congress instead of the airline.
Programming and Travel are Fragile Systems
The idea for this article came from Antifagile, where Nassim Taleb discusses how small changes create exponential problems.
Travel is familiar to all of us, so when we think about the delta, which represents the small changes, picture it as the time delay or increase in transit time.
Consider the effects of 3 different deltas
Consider my layover in Newark. How late can I be before I miss the connecting flight. If I miss the connection, how long does it delay me?
20 分 – The change here is minimal. I will suffer a great deal of (probably unnecessary) stress. My wife and I might jog across the terminal, looking slightly foolish in the process. それにもかかわらず, the chance of making the connection is near certain.
60 分 – This is scenario is right on the verge of disaster. My poor wife will listen to me groan and bite my nails as I flip out about missing the connection.
If we do make the flight, it’s only because the airline decided to hold he flight at the gate. Doing so inconveniences hundreds of waiting passengers while a handful of travelers scurry to board the flight.
If they don’t hold the flight, まあ, then I’m screwed.
The best scenario the can occur after missing the connection is that the airline transfer us to another European destination. The airline then needs to put us on a partner airline to fly us into Dublin, backtracking where we just came from. A one hour delays causes us to
- Wait for another European flight
- Fly an extra hour to a different destination
- Wait for a Dublin connection in a different airport
- Fly an hour backtracking
A delay like this could easily result in a an extra 6-8 hours of travel time- all from a 1 hour delay.
3 hour delay – Catching another flight to Europe looks really optimistic. The best case is that the airline put us up in a hotel for the night and sends us on tomorrow’s Dublin flight. A 3 hours delay expands to a 24 hour wait, plus the remaining flight time.
Programming
わかりました, ショーン, わかりました. What does his have to do with programming?
Just like traveling, a programming project can only go so well. Whenever something unexpected occurs, the problems compound themselves exponentially.
The Evil Delta
Time is the enemy of the traveler. In programming trading robots (or programming anything, 本当に), the delta is the degree of surprise.
Operating system changes: We developed a custom MT4 plugin for a client that likes to trade price ladders. One week after delivering the software, Microsoft released an operating system update. The update broke code in the software that we provided.
通信: You believe that you asked for one thing, but you get another. Items that seem like minor oversights can blow up into major problems.
Chris worked on a project last month that sought to execute a trading grid at precise intervals. Chris’ original version used market orders. A handful of bugs popped up, but the core of the original version worked well. The client, しかし, assumed we would use pending orders and requested that it be changed.
The change ruined the original design. もっと重要なこと, we discovered that achieving exact execution was fundamentally impossible because we couldn’t precisely control the execution time.
What started off as a 5 hour project blew up to 30 hours of work. The delta from communication surprises is evil.
Basic market mechanics: Sometimes we get asked questions where the trader should know the answer. A common trader-induced question that we get asks why trades suddenly close at market. Traders should have enough knowledge and experience to avoid such basic problems.
The delta on these issues varies, but they’re not as severe as communication issues. They can go anywhere from 20 minutes spent researching the issue to several hours.
Things that can go right in a programming project
- Deliver code on time. The time requirements for on time delivery are the easiest to predict. Projects start with a goal. The coder has a good idea for the amount of time required to build a working version.
I view this as analogous to a flight crew arriving on time. The bar is pretty low here. - The code works bug free the first time – no doubt your first response here is, “That’s the way it should be!”. It’s certainly the way that I’d like it to be, but it often doesn’t work out that way.
Most software problems result from communication. When we write a scope of work and program an 専門家アドバイザー, we believe that we fully understand the requirements.It often turns out that some of the requirements were not communicated. The product literally follows the order. It’s only when viewing the trades enter the market that the client realizes that they did not ask for something – just like the client that wanted pending orders instead of market orders. They incorrectly assumed that was understood when it was not. The experience of seeing the missing features is the only way the user recognizes the oversight.
- Treat people nicely – Programming is a service, but nobody wants to feel like the person on the other end only cares about money. I genuinely care about designing trading systems and helping people. When a customer does business with OneStepRemoved, I want them to trade better and to know that we care about their long term success.
You can always email me personally if you feel you’ve been treated otherwise.
What kind of surprised have you dealt with when programming your trading robot? Share your experiences in the comments section below.
