oblique programming strategies

Ever since I found out about it (probably on Hacker News), the idea of Oblique Strategies has fascinated me. The first editions are going on ebay for $2500-$3300 bucks, which I think is incredible. If you’re curious and impatient, you can check out this list on github.

One recent sleepness night, I made a list of “oblique programming strategies” on my phone, transcribed here. They are not as starkly polished as Eno’s version (unsurprisingly), but might be useful to you!

• Solve the easiest possible problem in the dumbest possible way.
• Write a test for it.
• Is there a better name for this thing?
• Can we move work between query time (when we need the answer) and ingest time (when we see the data that eventually informs the answer)?
• Is it easier in a relational data store? A KV Store? A column store? A document store? A graph store?
• Can performance be improved by batching many small updates?
• Can clarity be improved by transforming a single update to more smaller updates?
• Can we more profitably apply a functional or declarative or imperative paradigm to the existing design?
• Can we profitably apply a change from synchronous to asynchronous, or vice versa?
• Can we profitably apply an inversion of control, moving logic between many individual call sites, a static central definition, and a reflectively defined description of the work to be done?
• Is it faster with highly mutable or easier with completely immutable data structures?
• Is it easier on the client side or the server side?
• List the transitive closure of fields in a data model. Regroup them to make the most sense for your application. Do you have the same data model?
• Is it better to estimate it quickly or compute it slowly?
• What semantics do you need? Should it be ordered? Transactional? Blocking?
• Can you do it with a regex? Do you need to bite the bullet and make a real parser? Can you avoid parsing by using a standardized format? (A few to get you started: s-expressions/XML/protobuf/JSON/yaml/msgpack/capn/avro/edn.)
• What is the schema for this data? Is the schema holding you back?
• Draw a state diagram according to the spec.
• Draw a state diagram according to the data.
• Draw a data flow ($dX/dy$)
• Draw a timeline ($dX/dt$)
• How would you do it in Haskell? C? Javascript?
• Instead of doing something, emit an object.
• Instead of emitting an object, do something.
• Store all of it.
• Truncate the old stuff.
• Write the API you wish existed.
• Make an ugly version where all the things work.
• Make a gorgeous version that doesn’t do anything.
• Can you codegen the boilerplate?
• Enumerate all the cases.
• What happens if you do it all offline / precompute everything? What happens if you recompute every time? Can you cache it?
• Can you build an audit log?
• Think like a tree: ignore the book-keeping details and find the cleanest representation.
• Think like a stack: zoom in to the book-keeping details and ignore the structure.
• Replace your implementation with an implementation that computes how much work the real implementation does for that problem.
• What is the steady state?