Suffering-Oriented Programming by Nathan Marz.
From the post:
Someone asked me an interesting question the other day: “How did you justify taking such a huge risk on building Storm while working on a startup?” (Storm is a realtime computation system). I can see how from an outsider’s perspective investing in such a massive project seems extremely risky for a startup. From my perspective, though, building Storm wasn’t risky at all. It was challenging, but not risky.
I follow a style of development that greatly reduces the risk of big projects like Storm. I call this style “suffering-oriented programming.” Suffering-oriented programming can be summarized like so: don’t build technology unless you feel the pain of not having it. It applies to the big, architectural decisions as well as the smaller everyday programming decisions. Suffering-oriented programming greatly reduces risk by ensuring that you’re always working on something important, and it ensures that you are well-versed in a problem space before attempting a large investment.
I have a mantra for suffering-oriented programming: “First make it possible. Then make it beautiful. Then make it fast.”
First make it possible
When encountering a problem domain with which you’re unfamiliar, it’s a mistake to try to build a “general” or “extensible” solution right off the bat. You just don’t understand the problem domain well enough to anticipate what your needs will be in the future. You’ll make things generic that needn’t be, adding complexity and wasting time.
Different perspective than Semantic Web proposals for problems that users don’t realize they have. (Topic maps have the same issue.)
I was going on, probably tiresomely, to my wife about a paper on transient hypernodes/hyperedges and she asked: “Is anyone using it now?” I had to admit 22 years after publication, it had not swept the field of IR.
She continued: “If it was so good, why isn’t everyone using it?” A question to which I don’t have a good answer.
RDF and OWL interest the W3C and funders of research projects but few others. There is no ground swell demand for an ontologically enabled WWW. Never has been.
At least not to compare to the demand for iPads, iPhones, photos of Madonna/Lady Gaga, NoSQL databases, etc. All of those do quite well without public support.
But then there is real demand for those goods/services.
Contrast that with the Semantic Web which started off by constructing universal and rigid (read fragile) solutions to semantic issues that are in a constant process of dynamic evolution. Does anyone see a problem here?
Not to excuse my stream of writing about topic maps. Which posits that everyone would be better off with mappings between representatives for subjects and their relationships to other subjects. Maybe, maybe not. And maybe if they would be better off, they have no interest.
For example, for sufficient investment, the World Bank could enforce transparency down to the level of national banks or lower for its disbursements. That begs the question whether anyone would accept funding without the usual and customary opportunities for graft and corruption? I suspect the answer both within and without the World Bank would be no.
A little bit closer to home, a topic map that maps “equivalent” terms in a foreign language to subject headings in a library catalog. Composed by local members of a minority language community. Not technically difficult, albeit it would require web interfaces for the editing and updating. How many libraries would welcome non-librarians making LC Subject Classifications accessible to a minority language community?
Here’s a question for suffering-oriented programming: How do we discover the suffering of others? So our programming doesn’t satisfy the suffering of an audience of one?