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
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.

Transcript

1. Building better software through mathematics (And no, I don't mean formal verification) Greg Brockman Stripe CTO // @thegdb
2. Mathematical problem-solving techniques are dual to software engineering techniques. ! Proof by example to follow.
3. Mathematical low road Define “determinant” as a formula of various pieces of a matrix. ! Use symbolic manipulation to prove a bunch of interesting properties. ! It’s exhausting, but it works.
4. Translated to engineering… Just bang code into your editor. ! Easy to produce but hard to maintain or extend. ! This is what programming is for many people.
5. Translated to code… my_hand = ["2C", "2D", ...].shuffle your_hand = ... ! while true my_card = my_hand.shift your_card = your_hand.shift ! compare = compare_cards(my_card, your_card) if compare > 0 ...
6. Mathematical middle road Define “determinant” as a function with a few specific properties. ! Oh hey, it’s easy to show existence and uniqueness. Use these properties to easily derive a formula. ! It’s a clever way to solve the problem at hand.
7. Translated to engineering… Decompose your program into modules. ! The implementation of those modules should follow naturally from their interface. ! If it’s hard to implement any one piece, you haven’t decomposed enough.
8. Translated to code… class Card; ...; end class Hand; ...; end ! class War def initialize @my_hand = Hand.new @your_hand = Hand.new end ! def start my_card = @my_hand.draw your_card = @your_hand.draw if my_card.beats(your_card) ...
9. Mathematical high road Build the theory of exterior product space. Determinant is a special case of this general theory. ! All our desired properties are obvious. ! This is the “Ender’s Game” approach to problem solving.
10. Translated to engineering… Break a system into fundamental units, and design very general abstractions around them. ! This is really, really hard. ! When you get it right, everything else becomes easy. When you get it wrong, you never ship.
11. Translated to code… class War < AbstractCardGame players 2 loss_condition {my_hand.length == 0} victory_condition {your_hand.length == 0} on_win “add_card_to_deck” end
12. Mathematics is just software with a more expressive, more performant programming language.
13. Software does have its advantages though…
14. Mathematics: Software engineering:
15. Can we apply learnings from mathematics (which has had thousands of years to mature) to build better software?
16. Yes. (Ok, it’s not really fair to answer my own rhetorical questions.)
17. Elegance through least action Mathematical elegance comes from a stubborn unwillingness to do unnecessary work — refusing to accept anything but the simplest, most compact solution. ! In software, choose the design that requires to unnecessary work for your user. Example:
18. Understand how your abstractions are implemented To use a theorem, you need to understand its proof. ! In software, if you don’t understand how the abstractions you use are built, you won’t understand the resulting system.
19. Design software down but build software up The concept of “brute force” as a shortcut is well-understood in math. You’ll generally brute force by hand. ! In software, your CPU can instead do the brute force. Take advantage of this to get software built faster.
20. Greg Brockman Stripe CTO // @thegdb