Suffering-Oriented Programming
DZone 's Guide to
Suffering-Oriented Programming
Join the DZone community and get the full member experience.
Join For Free
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.
-
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.
Like This Article? Read More From DZone
Topics:
Published at DZone with permission of Nishant Chandra , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}