Starting up in Operational Research: What Programming Languages Should I Learn?

A ThinkOR blog reader asked me some questions about getting started as an Operational Research professional. The reader is in his final year studying Mathematical Statistics, and is preparing to get into an OR master's degree upon graduation. I think these might be some common questions about starting up in OR, so I'm publishing my answers here as a mini-series on "Starting up in Operational Research".

Question 1: What programming languages should I learn?
"I'm a bit interested in what programs and programming languages you would recommend to learn? May seem like a silly question, but since we use a few different programs in university, I'd like to focus on the programming languages which are most widely used/accepted. Our main tool at the moment is R, with some Matlab thrown in for Econometrics and larger matrix calculations. Would you consider R a well used tool in OR or is it mainly used in academics but not in real life?"

I think it is not so important as to what language to learn, but to learn the basics of programming well, so that you can pick up any language easily in the future.

The reason I say that is because:

1. The OR application and software world is very fragmented. There are many different applications, and they seem to like having their own proprietary languages. However, most of them are developing a Graphical User Interface (GUI) for non-programmers, since they are often aimed at business users (that's where the money is). That said, if you want to fully utilize a software's potential, especially in the case of simulation software, you'd better learn its own language, which is usually proprietary. This would require you to pick up a new language.
2. Most of these proprietary languages are quite low level languages. Therefore, it is important to have a solid foundation in programming. It will help you understand the language and learn it fast.

My undergraduate degree was in Computer Science (CS). I learned quite a few different languages, but did not really get to use them in Operational Research. However, my CS education helped me to pick up the programming languages needed in OR very quickly. Here I will list the main languages that I encountered in OR:

• VBA
• SAS
• R

VBA is the number one, since a lot of models are done in Excel. SAS is probably the most used in business and a required skill by many employers. Matlab is more for researchers, I believe. I haven't seen it used in any commercial setting so far. I do believe R is used in some commercial settings though.

Note: needless to say, these are only my thoughts on the topic. Please feel free to chime in.

London King's Cross train station platform utilization

In a previous article, Maximizing airport runway & boarding gates utilization at London Heathrow, I talked about the assignment of boarding gates at London Heathrow Terminal 5. They are not assigned until about 40 minutes before departure. I suppose it would only be logical to find the similar approach used on train station platform assignments in London's King's Cross rail station.



As can be seen on the picture above, platforms are assigned only about 15-20 minutes before the train's departure time. They appear to be using a hot platforming system similar to the gates at T5. This has it's advantages and disadvantages though.

It creates a commotion in front of the information board once the platform is finally assigned. Streams of people start to pour away from the information board, which is in the centre of the rail station, making foot traffic rather chaotic. For one train we took, it was so chaotic that the train narrowly managed to depart on time, and it seems likely that delays are sometimes caused. Also, there is always a huge crowd of people waiting in front of the info board at any time, with their pieces of luggage, which again makes foot traffic congested.

Then again, as the crowd of Friday-afternoon-bank-holiday-Monday-weekend travelers pushed to board the KGX to Leeds train, we were met by a team of 8+ ticket checkers who processed us efficiently. These resources only had to be assigned for the 15 minute window between platform announcement and departure. Another possible advantage might be the ability to allow travelers to depart incoming trains before being crowded by outgoing passengers. This suggests the possibility that the platform is known but not announced in order to manage foot traffic, though they are having mixed results given the disadvantages listed above.

Lean Airport with Clear Measurement at London Heathrow

The London Heathrow Terminal 5, which cost 4.3 billion pounds to construct, was described to be a "national embarrassment" for the UK due to its chaotic and "mayhem"-like opening on March 27th, 2008. Blames were put on the problematic computer system behind the luggage belts. On the opening day, 34 flights were cancelled, passenger check-in's were suspended, 20,000+ bags were stranded due to the inefficient system, and passengers waited for hours because of it.

Less than one year later, the London Heathrow Terminal 5 is doing very well. Going through the London Heathrow airport recently, I noticed the following sign just past the Terminal 5's security check point, which screamed "lean operations" to me. It measures and reports on the terminal's various wait time, service availability, overall ease and accuracy, as well as cleanliness.

In particular, the measurement of "Flight information" in the following photo is related to the last article on Maximizing airport runway & boarding gates utilization at London Heathrow, where I talked about the flight information board of gate assignment. It seems like all targets were achieved and some were exceeded. Well done.

Also, the reporting on "Security waiting time for transfer passengers" reminded me of a project done in 2003 by the Centre for Operations Excellence at the Sauder School of Business in the University of British Columbia with the Vancouver International Airport (YVR). The project team created a simulation model to form optimal staffing requirement for the security check point to meet the target of "90% of customers pass through the security check point in 10 minutes or less".

I guess when people pay attention, things can be done properly. "The general consensus at the moment is that Terminal Five has put its initial problems firmly behind it. British Airways believes that the terminal now provides the 'best customer experience Heathrow has known' for several years. Furthermore, the airline holds frequent meetings with BAA in order to review the airport’s performance." (source: Heathrow Airport Guide)

Maximizing airport runway & boarding gates utilization at London Heathrow

Have you transferred at or departed from the London Heathrow airport lately? Did you notice how the boarding gates remain unassigned until approximately 40 minutes before departure for the inter-European flights?  See picture below. I noticed them doing this at least 2 years ago, but now as an Operational Research professional, I can appreciate some of the intuition behind it.

It allows the runway and boarding gate planners a lot of flexibility so that if a flight is late, the planner can easily swap gates and runways if needed with minimum communication to the parties involved. In terms of communication, it is less hassle and less mistake-prone. In terms of an optimization problem, this flexibility means fewer constraints, and therefore better solutions potentially.

Interesting note: see how there are 4 flights scheduled at 19:05 for departure? My flight was the 19:05 to Prague, and I was able to see that there were basically 2 runways for the group of gates in my area, and several planes (about 4) were lined up like ducks in a row waiting for their turns to take off one by one. However, the individual take off is quite fast. Therefore, even though the 19:05 departure time is somewhat approximate for the 4 flights, my flight to Prague certainly arrived on time nonetheless.

As a passenger, it was slightly annoying that when I arrived at Heathrow, I did not know which gate to sit at to wait for my departing flight. However, I was quickly assured that this would not be a problem, because another information board tells me how long it would take to get from where I am to another gate, so I did not need to worry about being late for boarding. See picture below.

I suppose this could also be applied to the domestic flights in other parts of the world, such as the USA and Canada.

ThinkOR's Operational Research traveling tidbits

As previously mentioned, ThinkOR's authors, Aleksey and Dawen, have moved to Europe and are now looking for Operational Research type of jobs in western Europe in countries like Germany, the Netherlands, Belgium, Denmark, UK, etc. Aleksey and Dawen are now on the road a lot, evaluating potential cities to live and work in, while checking out the local OR employment opportunities. On these trips, you will see notes by us about interesting applications or references to OR topics, such as the 2 articles before by Aleksey:

• Lean Prison Management - Alcatraz, San Francisco, California, USA
• Keynesian Economics in 1360 - "the hungry wall", Prague, Czech Republic

Look out for more fun articles on operations research tidbits that we encounter on our trips.

Ciao!

Keynesian Economics in 1360?

I recently tripped across this in Prague. Originally built by Emperor Charles IV, this old city wall was built to protect Prague and some of it still stands today. Two local students who were touring us around the city told me that Charles IV had it commissioned in order to provide work for Prague's people who were suffering from a famine at the time. "Keynesian Economics!" I said.

I found this interesting in a time where the media, public opinion, and politicians suddenly all seem to believe and support Keynesian Economics completely.

Unfortunately the Prague city website reports that this is all a myth and that the wall was already under construction when the famine struck. This cannot be called stimulus money after all. For anyone who has been following the recent stimulus efforts, you could say that this wall was "shovel-ready."

Lean Prison Management

Two weeks ago, Dawen and I were in San Francisco. A mandatory tourist stop is the Alcatraz tour/cruise. Despite the poor weather, we elected to take the cruise and enjoyed an interesting visit to the island, including the award winning audio tour. While on this tour, we noticed an application of the lean principle of poka-yoke or mistakeproofing.

Alcatraz was a super-ultra-max security prison lasting 29 years from 1934 to 1963. High profile and extremely dangerous prisoners were sent here and security was tight. Guns and knives, naturally, were kept secure, but food still had to be prepared in the kitchen. Thus was born the knife board. This was a piece of wood in which each knife had it's shape cut out as a home so that it could be easily determined if a knife was missing.

Lean or Lean manufacturing has an interesting relationship with Operations Research. While Lean is not a component of Operations Research, many of the same principles are at play in its execution. They also typically share the same goals and the same field of play. Lean approaches can be excellent tools for implementing changes recommended by OR analyses. The focus of Lean is the elimination of wasted time and resources in business processes. The key to lean is the grass-roots approach it takes, involving process owners and front-line workers in the problem identification, and solution process.

The audio tour is a largely solitary endeavour, so we did not discuss it immediately. Being the sort of people that we are, though, Dawen and I both noticed this and spoke with each other about it immediately afterwards. It would be interesting to look for more applications of Lean to prison management. Perhaps one that minimizes inventory?

ThinkOR's authors looking for Operational Research positions in Europe

ThinkOR's authors are looking for exciting Operational Research and Operations Management work opportunities in western Europe. Aleksey and Dawen are moving from Canada to Europe to further and broaden their work and life experiences.

We are flexible in the cities we reside in and the industries we work in, so long as the problems are interesting and that we can contribute to the development of an exciting organization. If you or someone you know are looking to hire English-speaking OR consultants, please contact Dawen at dawen[dot]peng[at]gmail[dot]com and/or Aleksey at aleksey[dot]nozdrynplotnicki[at]gmail[dot]com. Our high-level resumes are available on LinkedIn (Aleksey and Dawen). Detailed resumes and references are available upon request. Your help is greatly appreciated. Advices are also welcomed on OR job hunting in Europe.

Since we will be in Europe, if you'd like to meet and chat, we'd certainly be glad to meet more fellow Operational Research professionals. Just shoot over an email to connect.

Breakfast optimization :)

At the end of his course on mathematical methods in optimization, the professor sternly looks at his students and says: "There is one final piece of advice I'm going to give you now: Whatever you have learned in my course - never ever try to apply it to your personal lives!"

"Why?" the students ask.

"Well, some years ago, I observed my wife preparing breakfast, and I noticed that she wasted a lot of time walking back and forth in the kitchen. So, I went to work, optimized the whole procedure, and told my wife about it."

"And what happened?!"

"Before I applied my expert knowledge, my wife needed about half an hour to prepare breakfast for the two of us. And now, it takes me less than fifteen minutes..." 

VBA: Alive and... Well?

The future of Visual Basic for Applications (VBA) has been recently called into question. In March 2008, Microsoft dropped their extended support for VB6 and the Microsoft Office 2008 for Mac did not include any VBA functionality.

This is a cause for concern in the applied OR community. In my recent post about the use of Excel for modeling, all four examples relied heavily on VBA. The ability to rapidly develop models using both cell formulas and VBA scripting is invaluable. Taking that a step further, the interface components and widely available platform of Excel are useful when developing end-user tools for clients.

Luckily our fears can be generally put to rest. An MSDN blog article: The Reports of VBA's Demise Have Been Greatly Exaggerated has assured us that:

"[T]he next generation of the Microsoft Office system will definitely contain all of the functionality that developers and power users expect from VBA."

None of this is breaking news if you're on the lookout for it, but if you're an academic director paying close attention to the relevance of your course/project work it's certainly a current issue.

Personally I'm more interested in the questions that all of this raises rather than answers. With Visual Basic (.NET) 9 and C# as viable options for interoperability between general purpose programming and Microsoft Excel, I find the more interesting question to be: Should we be coding tools with VBA?

Ease of development is one thing, but are we really asking too little of ourselves? Sure someone from a non-software development background can develop a subroutine for Excel, but is that really optimal? Personally I think anyone practicing OR should have at some point learned to code in a modern Object Oriented programming language. It's not that difficult and it really maximizes your efficacy. What it takes to teach someone to code pales in comparison to the sheer educational investment necessary to get someone from high school mathematics to Markov Decisions Processes.

With a little effort C# inter-operating with Excel could produce a much "better" solution than VBA. With a modern IDE and a little experience C# can be coded with relative speed. Indeed I did just this when producing a prototype tool for my Masters project. I must admit, though, that deployment did not happen completely without a hitch. Just because I know how to code does not mean I can comfortably shrug off all of the benefits of VBA/Excel including deployment-by-mailed-attachment.

Philosophically matching the weight of the task to the weight of the approach is difficult. It would be irresponsible to code a truely complex application in VBA. Then again, it might be dishonest to dress up a hatchet job of a solution in the guise of an industrial application.

To sum the above three paragraphs up, the part of me that almost took Computer Science as an undergradutae degree fails to find VBA as an acceptably elegant solution. That said the (clearly much louder) part of me that DID take a Business graduate degree sees the silver lining:

• I read an article by Simon Murphy defending VBA and much of it rang true.
• Some would promote OpenOffice Calc as an alternative to Excel because it's free and non-proprietary. I would disagree. Excel/VBA solutions are good because their platform is free at the margin. Every organization has, has had and will have Excel, making its continuing use essentially free.

What can I say? The debate will continue to rage on. I find it hard to draw a conclusion for this article, but I will leave our OR readers with a thought: Recall the Simplex algorith. Something doesn't have to be perfect in theory for it to be excellent in practice.

Love it or hate it VBA is here to stay. With its inclusion in current and future MSOffice products (with the exception of Mac 2008, but who cares anyway? ;)) we can safely continue to use it where appropriate. We can continue to teach it to our Masters students as a gold standard of business programming.