5 cakes do not make a developer

A workshop on the basics of linear programming

During our monthly workshops we exchange knowledge and try out new techniques in practice straight away. The topic this time: linear programming. You learn how to turn a problem into a mathematical model and then optimise it.

Linear Programming is still fairly untrodden ground for most of us. But the principle is cool: rewrite your problem into a mathematical model and let a piece of software calculate the optimum for you. We were given a nice example where you determine the maximum profit of a patisserie in exactly this way. Taking into account cost price, preparation time, wages and the like. That way a cheesecake might yield more margin than a simpler carrot cake, but it is also much more labour-intensive in proportion (sidenote: I know software, not cakes, so it could also be that cheesecake actually yields less or is ready faster than a carrot cake, I am completely digressing). You can also include production costs. With a dose of mathematical magic you set up a formula for that.

Getting to know PuLP

You present that formula to PuLP. A Python libraryGlossary · In brieflibraryA library is a collection of reusable software code for a defined task. An application can call that code to use existing functionality.Read more⁠ that can handle this kind of problem. You build a little model, and put the production costs, the production time and the yield into it.

After that you simply add your profit maximisation objective and hit play. If everything went well, the model shows the optimal outcome. Not quite right? If you forgot that a cake baker also wants to sleep and does not want to work 80-hour weeks, something rolls out that is pretty hard to carry out in the real world. PuLP does a lot for you, but you will really have to indicate yourself what all your requirements are.

On to practice

This was a purely theoretical case during the presentation. For the cake lovers among you therefore unfortunately no brief recipe for an immeasurable fortune. The real workshop goal was namely a lot tougher: automating our own monthly planning. As employees we no longer dance that monthly manual round, an exercise that with more and more developers and projects seems to have become quite time-consuming. Our dear bosses saw the perfect match in it: you teach all our developers something about such a Programming puzzle, and along the way you make planning a lot less nightmarish.

Went super well surely?

Insert success story here

During the workshop we looked at whether that could even work, and if so, how. You quickly find out then that you have to take an idiotic number of things into account at once. Of course you do not want to slam all your developers onto that one project. Besides that such a model has to do something with days blocked in advance, think of client meetings or my trip to Bali. How you capture all of that in one model... do not call me.

Addition from Bauke

With linear programming everything apparently revolves around solvers. Maximise the profit on cakes, given ingredient costs, baking time and the baker's wage? Solvers! The best deployment of trucks and drivers, reckoning with distances, mandatory rest and cargo weight? Solvers! Or, what this workshop did, smartly distribute your staff over projects based on who is suited where and present. Solvers!

Sounds simple. But apparently you first have to give that solver something it can actually run on, and exactly that turns out harder than expected. You then roughly have three tasks:

• Defining and quantifying the right variables. (What all plays a role in your optimal calculation - for example degree of suitability for a project?)
• Defining the objective function (How should the optimal result be reached? - for example most optimal match between suitability and project)
• Defining bounds and constraints (Within which frameworks must the calculation be done? - for example who is free on which day?)

And very quickly after that you notice that a variable is missing, or a constraint is set too soft. My very first planning promptly had everyone full-time tinkering on the same project, maybe then take into account that a project may not run infinitely many hours per month. After a while of fiddling I managed to lay that extra restriction in neatly. Nice! An hour further on I eventually had a decently working planning, although a truly optimal result still requires quite some fine-tuning.