Jean-Francois Puget, a friend and former colleague, recently kicked off an interesting conversation with the following tweet.
I always wondered why deep learning community managed to create frameworks that can be used without a PhD while the mathematical optimization community didn't.
Deep learning isn't simpler than, say, MILP. But it is perceived as being easier to use.
JFP is one of the few people who can speak with authority about both Mixed Integer Programming (MIP) and deep learning. I consider him a thought leader. As expected, the general tone of the many responses to his tweets was fairly consistent. “Indeed, we need to promote MIP adoption by making it simpler”.
I’m going to leave aside the question of whether or not deep learning is simpler than MIP (I tend to agree with Marco Lübbecke’s response here) and only discuss whether or not we should try to make MIP simpler than it is now. My answer is contrarian. We shouldn’t be making things easier for MIP students. We should be making things harder.
More specifically, we should stop teaching (either implicitly or explicitly) a fictional world in which the only hard part of MIP is creating the mathematical model. This idea (“The math is the hard part”) leads one to the following misconceptions.
The client understands what problem they need to solve.
The client has clean data readily available.
The client won’t change their mind.
All these are false. That's not to say that MIP practitioners never encounter such wonderful clients in practice, but rather, the typical place to find such clients is in a university, where your “client” is actually a professor and your work product is a homework assignment. MIP instructors should recognize these three assumptions as useful fictions. They are indeed helpful to bootstrap the learning process, but once students have developed confidence in mathematical modeling, they can be introduced to the non-mathematical challenges that can confound a successful MIP engagement.
The client doesn’t understand what they need.
The client is likely to give you dirty data.
You should expect to build your MIP engine iteratively, if for no other reason than the client will change their mind once they see something in action.
The skills needed to address this reality are broadly categorized as “soft” and “hard”. While I certainly don’t want to imply that the latter is more important than the former, my area of expertise (and thus the remainder of this blog post) will discuss software development best practices as they pertain to MIP. If you’re more interested in consulting skills, then you should continue to follow this blog. When it comes to the art of client success management, you’re unlikely to find an educator more accomplished than Mike Watson.
MIP is typically taught by Industrial Engineering / Operations Research (IEOR) professors. The challenges I describe above are more naturally in the domain of Computer Science. They are the sort of problems discussed in a software engineering class, which is usually the third or fourth class taught on the way to a CS undergraduate degree.
I have a CS degree. Two of them, even. I’ll let you in on a secret. IEOR students can skip all that, and self-study the following two domains.
The Agile software development methodology.
The Python programming language.
As luck would have it, IEOR students are probably already teaching themselves Python, using a wealth of online resources as their instructor. It is now the most popular programming language in the world, and also the dominant language in data science. The missing piece is how to apply the common sense methods of Agile using the Python programming language. Specifically, the skills that need to be addressed are the ability to do the following.
Distribute your MIP engine as an installable, versioned, piece of software.
Bombproof your MIP engine against dirty (that is to say, realistic) input data.
Curate a suite of input data sets with which to test your MIP engine.
The skills can then allow one to have the following sort of interaction with a client.
Ahh, I see your point. Indeed, the input data field Blah isn’t doing what we need it to do. In fact, what we need here is an additional input table to replace field Blah.
The engine you are running now is version X. I’m going to give you version X+1 in a few days, and it will replace X when you install it. Don’t worry about the input data sets you have built now. I need to write a subroutine that converts version X input data into version X+1 input data in order to upgrade my test suite,, and I can just expose that functionality for you so that you don’t need to manually rebuild your current models when you upgrade.
At this point, perhaps I’m starting to sound a bit like Winston Churchill in the runup to Dunkirk. "I have nothing to offer but blood, toil, tears and sweat." I’ll let you in on another secret. I’m just not that macho. I’m not asking anyone to do anything that is terribly hard.
Let me put it another way. If you’re already confident with the basics of MIP modeling, you know enough Python to build a MIP engine in a single script file (or a Jupyter notebook), and you’re passing the rest of the classes in the IEOR curriculum, then the hardest part is behind you. You’re the target audience for whom my proposed missing skill set is relatively easy to acquire. I’m not optimistic about the idea of “Python expertise for everyone”, but for someone like you, it’s a safe bet.
If you agree, then follow me on LinkedIn or Twitter. I maintain an open source Python package that I use to meet these requirements in my own work, and I’ll be publishing free, educational materials to help other MIP students learn what I’ve learned. I promise you that my tone won’t run to the Churchillian. Instead, I’ll try to emulate Billy Beane and Ron Washington from the movie Moneyball, as they encourage Scott Hatteburg to learn how to play first base.
BB: It’s not that hard Scott. Tell em Wash.
RW: It’s incredibly hard.
BB: Hey, anything worth doing is. And we’re going to teach you.