Mathematics and Modern Software

November 16, 2018

The lie I told myself coming out my undergraduate education (and the lie I often hear a bunch of other people saying) is that programming doesn’t really have anything to do with mathematics. They just seemed so weakly connected. Why did I have to take three quarters of calculus when discrete mathematics was going to be the only mathematics course that seemed remotely applicable to programming?

Modern software products are built on libraries and frameworks that handle most of the mathematics. This is why web programming is so approachable. It’s not an easy problem to determine how packets should get transmitted over a wire to server a web page, or how to programmatically modify the compilation of a program — but that’s rarely required to build a modern technology product.

In 2016 one of my mentors at Coursera told me to solve a single problem: reduce the error rate of our Javascript applications. We were simply letting too many things break.

I started by trying to promote TDD. That didn’t work too well because once the pressure of deadlines was inserted into a project by a blissfully ignorant product manager, the incentive to write tested code would just magically disappear.

I tried the approach of promoting ratcheting up test coverage over time by encouraging a test coverage % to go up on a code package and never allowing it to drop unless there were extenuating circumstances. While this worked, engineers were extremely unhappy and started to increase test coverage in the least effective areas (but un-surprisingly were the easiest to test)

It wasn’t until the product organization pulled on some enterprise customers and the company was contractually obligated to 99.95% uptime that teams started to build in time for effective test writing. (I think this is actually a great strategy, but I also think not all companies have to enforce uptime in contract to work towards lowering error rate)

The last thing I tried was promoting static typing – and despite the slow start and the inability to scientifically measure exactly how much effort put into static typing lead to X result, once developers learned the type system, it was clearly something that was inherently understood as “a good thing”. (Ergonomics around type system tools are also incredibly important. Flow from Facebook is an example of a tool that was hard to sell initially because of how unreasonably helpful the output was. It has since come a long way.

In my pursuit of static typing, I’ve gone through a whole phase of re-learning different languages with different type systems: OCaml’s and Haskell’s, to name the prominent ones – and I’m still trying to grasp the extent of their power. One thing that I’ve found a newfound interest in on this journey is mathematics. More specifically the mathematics behind the theory of static type systems and it is all extremely fascinating and I have a new empowerment to build systems that don’t cause consumers distress.

A couple of good talks I watched this month and would highly recommend if you’re debating whether or not you should dive deeper into static typing:

If you have trouble with Haskell notation (which is the most common basis for explaining functional concepts that might seem scary, but really aren’t, like Monads, I highly recommend spending an afternoon and going through Happy Learn Haskell Tutorial.

Written by Lewis Chung. Founder @ ShopWith. Previously: Coursera, Amazon. Writes about technology, products, and life.