Building better software through mathematics

Building better software through mathematics

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

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.


Greg Brockman

January 30, 2014