Adept as I am at adapting towards stupidity, your cynicism seems realistic.
Sunil Tanna makes the good point that we need developers because most people cannot "decompose problems into small units, or to assemble solutions out of small units." Both sides: decomposing and assembling,are necessary of course.
You've pointed out before that there's no getting around programming being a discipline requiring a long time to master. But among end-users there is a minority who have facility breaking problems into small parts and building solutions from small parts.
There seems some room for optimism that the "lego" approach might improve the experience of conversations between developers and end users of the able-minority, reducing time and frustration.
Short summary : metaphors are sometimes good but sometimes *hide* important details. The charitable way of understanding my law is that the more you try to make stuff easy by hiding stuff from the user, the less well informed she is, and more detached from what's really going on. In turn that disempowers her and makes her appear more stupid.
The problem with lego-bricks is that they're not a good metaphor. The fact that you stick module A together with module B tells you very little because typically A and B have more complex interfaces and it's how those are wired together that carries most of the information.
OTOH I think both the "pipeline" metaphor of eg. Yahoo Pipes, and the spreadsheet metaphor are likely to be much better for empowering users to build complex computer systems.
3 comments:
Adept as I am at adapting towards stupidity, your cynicism seems realistic.
Sunil Tanna makes the good point that we need developers because most people cannot "decompose problems into small units, or to assemble solutions out of small units." Both sides: decomposing and assembling,are necessary of course.
You've pointed out before that there's no getting around programming being a discipline requiring a long time to master. But among end-users there is a minority who have facility breaking problems into small parts and building solutions from small parts.
There seems some room for optimism that the "lego" approach might improve the experience of conversations between developers and end users of the able-minority, reducing time and frustration.
damned Blogger lost my long comment!!!!
Short summary : metaphors are sometimes good but sometimes *hide* important details. The charitable way of understanding my law is that the more you try to make stuff easy by hiding stuff from the user, the less well informed she is, and more detached from what's really going on. In turn that disempowers her and makes her appear more stupid.
The problem with lego-bricks is that they're not a good metaphor. The fact that you stick module A together with module B tells you very little because typically A and B have more complex interfaces and it's how those are wired together that carries most of the information.
OTOH I think both the "pipeline" metaphor of eg. Yahoo Pipes, and the spreadsheet metaphor are likely to be much better for empowering users to build complex computer systems.
Thanks for clarifying. I was here to get the link to this to share it. Your observations about metaphors are quite thought provoking.
Off topic, I like the Twitter model very much in this blog.
Post a Comment