Oblique programming strategies | Hacker News Reader

Oblique programming strategies

traviscj.com

178 pointsbased225 comments

Open articleView on HN

- Write down, in paragraph form, absolutely everything I know about the problem

- Implement it in pseudocode

- Write the simplest code that will work end-to-end, and work outwards from there

- Find a library that does it

Love these. Can't believe I missed "Find a library"!

Sometimes importing/depending on a library is exactly what's needed.

Sometimes importing/depending on a library means you're permanently saddled with an unmaintained, inflexible, third-party white elephant.

These outcomes are not mutually exclusive. One of my apps even has a directory called "lib/boondoggles/" because it includes so many of these. It works fine, but I will never revise it.

Author here, quite flattered to see the attention on HN! I would be quite open to feedback, additional mental de-blockers others have picked up, and/or requests for clarifications that I could expound upon. :-)

I was introduced to the Creative Whack Pack in college. It does come in handy. I think it predates Eno's version.

https://creativewhack.com/product.php?productid=64

Interesting!

Looks like Eno's was 1975 and CWP was '89, but I think the title+description+prompt is actually closer to what I'd originally intended to / would make if I had fleshed it out fully.

I occasionally use these two:

* What would we do if there was an order of magnitude less time to solve the problem?

* What would we do if there was an order of magnitude more time to solve the problem?

This can flush out 'we would just buy/use XYZ tool/library etc.' for the first, and reveals fundamental things that we are ignoring for the second.

Ooh, a programming version of the reversal test! (https://en.wikipedia.org/wiki/Reversal_test)

That's always been a great trick for getting rid of "this is where we are, so justify all changes" and seeing whether your problem is one of inertia or real challenges.

- "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)?"

This is quite a valuable one; it's easy to default to one or the other without really thinking. I would add to the list:

- can I write a state transition diagram? (like the classical lift controller or vending machine)

- how did people solve this problem in past decades? (can lead you to the wikipedia rabbit hole, but gets you away from trying to pick a solution from the fashionable set. Answers of the form "with bits of paper" are acceptable and may be useful)

I would love to read a concrete example about these two:

> 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.

Think like a stack - e.g. take this from Redux documentation:

"In a more complex app, you're going to want different entities to reference each other. We suggest that you keep your state as normalized as possible, without any nesting. Keep every entity in an object stored with an ID as a key, and use IDs to reference it from other entities, or lists. Think of the app's state as a database." http://redux.js.org/docs/basics/Reducers.html#note-on-relati...

TL;DR Redux docs are telling you "Think like a stack: zoom in to the book-keeping details and ignore the structure."

Think like a tree - e.g. NoSQL databases which allow for keeping hierarchical objects in database (in contrast to relational databases like MySQL).

Love the idea, but to work effectively I believe the card descriptions have to be more synthetic / abstract, both to make them fit into more contexts and force the reader to interpret them.

Completely agree -- My original intent when I scribbled them out was to make the long ones pithier and add some personal interpretation to the short ones. Life's a work in progress, I guess.

That's almost another one right there :)

MVP validation data point: please develop this into a physical product that my wife can buy me as a birthday present.

I love a lot of these. I might reference this the next time I get a sinking feeling about the path I'm taking.

Can someone explain this?

> 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?

I tried to do a quick job of explaining this, but the example that motivated this strategy was pretty work-specific and I'm not comfortable using that, and I can't come up with another offhand. Lemme tinker and see if I can come up with a good one!

"Transitive closure" is basically saying which states are reachable from other states in your data model.

For example, if you have a soft-deleted field "is_deleted" in your data model, then the transitive closure from "is_deleted" is the empty set, because nothing can ever change once an object is deleted(unless you support un-delete).

Maybe this is dumb, but when I wrote this I also took it to mean the "transitive closure" of different fields of your data. So if you had a object "a" with fields "b" and "c", you'd consider "a" and "a.b" and "a.c".

There's also an interesting relation here between reaching some state "S" and having some field "s_reached". I haven't been able to fully understand that relationship, though.

It's worth noting that original oblique strategies were invented by Brian Eno and Peter Schmidt in '70s: https://en.wikipedia.org/wiki/Oblique_Strategies

This is a lot of fun, thanks. I've always enjoyed the original oblique strategies, but a lot of them don't translate well from business to programming settings. These are a nice tweak.