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:
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:
The presentation is available here.
Published at DZone with permission of Nishant Chandra, author and DZone MVB. (source)- 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.
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
The presentation is available here.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Tags:
