Suffering-Oriented Programming

While exploring the Flume architecture, I came across a presentation called 'Become Efficient or Die: The Story of BackType' that coined a new term - 'suffering-oriented programming'. It is a simple concept which means:

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

Examples:
Growing from 2 people to 3 people.

Other interesting points from the presentation:

Over-engineering = Attempting to create beautiful software without a thorough understanding of the problem domain.
Premature optimization = Optimizing before creating “beautiful” design, creating unnecessary complexity.
Refactoring and reducing technical debt = Garbage collection for the code base.

Technical debt:

• W needs to be refactored
• X deploy should be faster
• Y needs more unit tests
• Z needs more documentation

Such issues are never high priority to work on, but they build up and slow you down.

The presentation is available here.