Suffering-Oriented Programming

Looked at a presentation deck on Slide Share the other day called Become Efficient or Die: The Story of BackType and one of the things that resonated with me is the concept of suffering-oriented programming.

In a nutshell:

  • Don’t add process until you feel the pain of not having it.

  • Don’t build new technology until you feel the pain of not having it.

  • First make it possible. Then, make it beautiful. Then, make it fast.

Mind you, while I get where they’re coming from, there might be something said for anticipating where your going to feel the pain and being a bit proactive instead of reactionary. I guess as with most things it’s balance.

Other points I liked:

Overengineering = Attempting to create beautiful software without a thorough understanding of the problem domain.

Premature optimisation = Optimising before creating “beautiful” design, creating unnecessary complexity.

Refactoring and reducing technical debt = Garbage collection for the code base.

Check out the whole presentation below: