How software gets written

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at:, or follow me on Twitter.

This is the history of almost every software project I can remember:

When I started preparing for teaching the chain rule in my class, I didn’t like the way the book did it. I felt like the proof was overly complicated and seemed to deliberately avoid an easier method. I couldn’t figure out why the author approached the proof the way he did. I started writing up different notes that I thought would be more clear. After a few hours of work, I realized that what made my method easier was that I assumed a simple case of the chain rule. Theorems are easier to prove when you assume they’re true in the first place!

I started to fix my mistake and discovered that I was also using slightly more restrictive assumptions, so my proof works for some functions but not for all functions. The method the author of the book chose works for functions that my method couldn’t tackle. I finally understood why he had done it that way in the first place!

Frustrated with myself, this phrase from Little Gidding popped into my head: “the end of all our exploring will be to arrive where we started and know the place for the first time.” T.S. Eliot wasn’t writing about math, but this sentiment seemed perfect for my situation, and for the way I feel about math in general a lot of the time. Only after extensive exploration do I fully understand the beauty or utility of earlier theorems or methods!

The big exception is when, after a great deal of work, I come to realize that the original programmer made a mistake. In those cases, I don’t finally realize why they did things as they did, but rather, I realize it is necessary to do things in a completely different way.

Post external references

  1. 1