Skip navigation

MIT Museum: CADR - The LISP Machine (late 1970...

MIT Museum: CADR – The LISP Machine (late 1970s) (detail) (Photo credit: Chris Devers)

A common thread through programming-philosophy (if such a beast even exists) is «worse is better». Program solutions that are worse end up being better, for reasons that, deep down, no one understands. The trope-namer is C × Lisp, where Lisp is the supposed uber-language, that can do whatever all other languages can, and still nobody uses it, while C is crap and everyone uses it. So what gives?This is all about orthogonality. A “good” tech in this sense is an orthogonal one. One that solves its problems in a simple, elegant way. It is engineered to have non-overlapping concerns, which means it does what it is meant to and not a lot of other stuff. This is important to allow focus, of course:

The design space for your business model shrinks in useful ways. — Ribbonfarm

The counter-intuitive part is that the most orthogonality that is imbued in a given tech, the less it becomes orthogonal in a general sense. That happens because designed orthogonality removes overlap between concerns under a given conception of the problem space. But the problem space is itself impossible to accurately map, and the orthogonality designed under a specific conception of it is likely to conflict with orthogonality in other mappings of the same problem space. In other words, over-engineering makes tools more specific and less general, in spite of having the exact opposite intention.

Piping

Piping (Photo credit: Voxphoto)

This means we must imagine our problem-space as multiaxial, which is to say, that we may not be able to say what the problem space is at all.

This is very obvious for a programming language, since it must be useful for weird stuff to be useful at all. But it is counter-intuitive for (say) a product managers, since it would seem to make sense that a product with more functions would be a better product. But the opposite is true, since a product with more functions is a product that has a more specific use case. Hence the minimally viable product is important not to generate revenue as fast as possible, but as an (almost anthropological) exploration of the problem space.

But this is a very relativistic perspective!

 

 

 

Enhanced by Zemanta

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: