Bold statement: A top 1% Operations Research practitioner will lose against a top 10% programmer in a hackathon. Unfortunately, I don’t have any emperical evidence to back this up, but my own humble hunch.
Nothing to be ashamed of, since an OR degree is multi-disciplinary, hence diluted across the many facets of the field — CS included. It’d be good for the OR industry if we all really learn to code.
I have a MSc in OR, but my programming skills were nowhere near the average CS grad, if it weren’t for my sabbatical studying Scheme, Common Lisp and Ruby on Rails to fill a void in my skill set. We were simply not taught (enough) real programming at school beyond the absolute minimum skills required to prototype your algorithm/theory — and churn out your school paper.
Ironically, we do learn about mathematical programming, linear programming, quadratic programming, etc.
Operations Research is a fascinating field of applying Mathematics, Statistics, Machine Learning, Artificial Intelligence, Simulations, etc. to solve real-life business problems. Awesome stuff, but how are you going to apply OR without programming?
Pretty tough. Unless you consider Excel’s solver to be Operations Research. Either that, or one of the plethora of modelling tools that enable ORites to circumvent coding to quite an extent, but which come with a price tag (open-source packages like R aside), but which might not fit the need of the problem you’re tackling.
Quite often, modelling approaches (I consider Matlab and R modelling) won’t suffice to address the complexity of a problem/approach and would require a custom implementation. The only language I could code in at the time was Java, which I didn’t like, so I decided to learn Lisp.
“Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot.” – Eric Raymond in “How to Become a Hacker.” Note that any language of your choice would do. I opted for Lisp for the above reason — and the below.
I blogged about the (Un)common Lisp Approach to Operations Research, where I made a point why I deem Lisp utterly suitable for rapid prototyping in OR.
Sim Cheng Hwee, president of IDSC — an OR consultancy in Singapore replied with: “I’ve not tried Lisp, but [while] it is possible to program a solution to solve a problem fast, […] one gets caught up with the database links, working the GUI, etc since users must be able to view, adjust their inputs and understand a solution before they can accept it and act on it.”
He made a good point. For OR to really make an impact (i.e. for an organization to adopt), we need to build a beautiful and easy to use GUI, link it robustly with scalable databases and these days deploy it to the cloud — while maintaining an elegant code base. In other words, we need some real hackers in the field.
It seem that in most cases, OR projects end up requiring 80% programming skills and 20% OR skills; the latter of which I’ll vaguely describe as anything OR related that CS grads don’t know, but nonetheless can pick up easily and much faster than ORites learn to code — elegantly anyway.
The Hacker vs the ORite
For now, let’s zoom in to the 20% with an example of one of my favourite puzzles in OR: Solving the Vehicle Routing Problem. Put simple, how do you minimize the total distance, while visiting all the clients within the time and capacity constraints?
Now, having an understanding of the problem at hand, the programmer would go and implement a library/platform to start and try solving the problem as good as possible. The ORite will put the rather simple problem into a mathematical framework and start “coding” in Latex. It’d kinda look like this:
Impressive, at least that’s what I always thought being a smug student back in the days, proudly turning in fancy papers with equations so beautiful it “makes you want to lick it”. In retrospect, those equations were completely unnecessary to the end product. I did not look back at these equations once, nor could I really use them in my coding endeavours, i.e. when it really mattered.
The end product was a model and algorithm written in Java to test the hypotheses. The final code base was not something I was proud of. Frankly, it was barfed up Spaghetti code. It was a quick and inelegant prototype, because I didn’t know better. A year later, I could not even get it to work (and I couldn’t stand Eclipse after getting used to Emacs).
Shame on you, hackers would say. Yes, shame on me, but I wasn’t trained to be a programmer. I’m still just an aspiring computer nerd, but I decided to do it over, this time as an Open Source VRP modelling framework written in Common Lisp — in an attempt to catalyze the research and application of routing solutions. (Feedback from real hackers would be highly appreciated.)
But the point is, I still prefer the easy-to-digest variant of the problem statement: “How do you minimize the total distance, while visiting all the clients within the time and capacity constraints?” That’s enough for me to start tackling it.
Solving the VRP
There are so many different solution approaches to the VRP, from Genetic Algo’s to Ant Colonies and from Simulated Annealing to Hybrid Algorithms — it’s not even funny anymore — but let’s not get into that. For the sake of illustration, let’s take arguably one of the most popular/powerful algorithms called Tabu Search. It is a very simple local search algorithm that I could attempt to teach a 12-year old. The pseudo-code is on the wiki page. Now let’s face it: who would do a better job implementing the Tabu Search algorithm — or any other (meta)heuristic for that matter — the hacker or the ORite?
Not to turn this into a Socratic Dialogue — which I’m doing anyway — but what do you think is the most important part of an OR publication, the mathematical formulation or the actual coding of the algorithm/approach?
Which one do you think decides whether or not your algorithm will outperform other papers? (The question answers itself, it appears).
Which one do you think will make an real tangible impact?
Remember, I’m now talking about the 20% OR part of the project, but as corroborated by Sim Cheng Hwee, 80% of the actual programming still needs to happen before the powerful ideas of OR are actually being applied.
And ultimately: Who would you hire for an OR project, the hacker with some OR knowledge or the ORite with some programming knowledge?
That’s my point. ORites should embrace more real programmers and programmers should try some OR. Some cross-pollination between CS and OR would be pretty explosive. But it needs to come from both ways. Top hackers in dire need of ideas, why don’t you have a look at the fascinating field of OR? There’s quite an opportunity there. You’ve got all the skills it takes. And we need you.