Nathan Marz: Suffering-Oriented Programming

Just read "Suffering-Oriented Programming" - a blog post from Nathan Marz (creator of Storm). The central idea is that you need to understand a problem well before you try to solve it properly - especially before you build generic abstractions to solve multiple use cases.  Beyond the ideas of YAGNI and MVP, the post outlines 3 distinct phases that are helpful to think about when setting out to tackle a tricky problem: 1) make it possible, 2) make it beautiful, 3) make it fast.

It has some great takeaway quotes:

• don't build technology unless you feel the pain of not having it
• reduce risk by ensuring that you're always working on something important 
• ensure that you are well-versed in a problem space before attempting a large investment.
• 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
• develop a "map" of the problem space as you explore it by hacking things out
• The key to developing the "beautiful" solution is figuring out the simplest set of abstractions that solve the concrete use cases you already have. 
• Don't try to anticipate use cases you don't actually have or else you'll end up overengineering your solution.
• development of beautiful abstractions is similar to statistical regression: you have a set of points on a graph (your use cases) and you're looking for the simplest curve that fits those points (a set of abstractions).
• most important... is a relentless focus on refactoring... to prevent accidental complexity from sabotaging the codebase
• Use cases are ... worth their weight in gold. The only way to acquire use cases is through gaining experience through hacking.
• attempts to make things generic without a deep understanding of the problem domain will lead to complexity and waste. Designs must always be driven by real, tangible use cases.