Many software engineers view their job as producing functionality

first, with any abstractions built along the way mostly an artifact of

how they happened to think about the problem. However, the best

engineers turn this model on its head, and view the set of

abstractions they build as the most important part of their work. It's

always easy to change your functionality if it's built on top of

well-designed, modular components, but changing to a better module

structure is difficult to impossible post hoc. (Believe me, we've run

up against this time and time again while building and scaling

Stripe.)

This is a secret mathematicians have known for centuries. In

mathematics, the only tool you get is abstraction. You can't rely on a

compiler or test suite to determine correctness, so like it or not

you're forced to break apart your problem into self-contained theorems

and lemmas. And in contrast to software engineers, who usually think

they're creating abstractions rather than discovering them,

mathematicians tend to end up with great abstractions because they're

never satisfied until they've found the most elegant possible

decomposition of their problems.

In this talk, I'll discuss the parallels between mathematics and

building software. Mathematics is a mature field, while software

engineering is just getting started, and so by exploiting these

parallels we can start writing better software without waiting for the

next few hundred years to go by.

January 30, 2014