Deconstruction of Computing

The Exercise

Brian Marick led a deconstruction exercise: The goals of the brainstorm are to uncover hidden assumptions and devise new ways to move forward. The starting assumption is that you’re bothered by the status quo or existing solutions, but you can’t quite articulate what’s wrong.

1. Explain deconstruction via an example.
2. In one big group, get people started listing privileged/marginalized pairs. Stop after filling one sheet of flipchart paper.
3. Break into groups of two. Each group keeps generating pairs until they find one they want to focus on.
4. For that opposition, they ask these questions:
   • What would a world be like in which the marginalized element were privileged?
   • Are there ways in which the marginalized element keeps popping up into view, no matter what effort is made to disregard it?
5. After the groups begin to wind down, have the groups of two coalesce into groups of four. Each half explains their idea to the other. Each half helps the other expand on their idea.
6. The whole group reconvenes. Volunteers present ideas they’re fond of.

Results of the Exercise

This exercise produced results and was to many quite satisfying. Though there seemed not to be much recorded about the exercise, the thinking it spawned ran through the rest of the workshop. Breaking up into pairs, then combining into fours, and finally coming together seemed to help solidify the thinking.

Here are some of the pairs we came up with:

• Either-or/Both-and
• Profitable/non-Profitable
• Expert/Luser
• Creating/Maintaining
• Professional/Amateur
• Education/Training
• Team/Individual
• Reading/Writing
• Rational/aRational
• Scientific/Artistic
• Deterministic/nonDeterministic
• Centralized/Decentralized
• Owned/not-Owned
• Old/New
• Code/People
• Likes-process/Doesn’t-like-process
• Fast/Slow
• Simplicity/Complexity
• Fast/Flexible
• Think/Talk
• Bounded/Unbounded
• Extrovert/Introvert
• Engineer/Scientist
• Science/Technology
• Developer/Tinkerer

Of these, we developed only one to any depth: Developer/Tinkerer. We looked at the current situation of home improvement in the US and the up-until-recent situation of automobile tinkerers, mostly in the US. There are a number of home-improvement TV shows on in the US, there are many, many home-improvement stores, books, videos, classes, consultants, and contractors to help do small jobs. In a world where computing tinkering would go on, there would be similar shows, artifacts, and roles for computer tinkering.

As a counter-argument to this, we started to try to imagine what it would be like for computing jobs to be of low prestige, and soon the elder members of the workshop recalled that in the 1960s and early 1970s, computing (coding) was menial labor, and "coding" did not simply mean transferring to punch cards the programs someone else wrote - it meant taking fully general equations or "requirements" and devising a program or system to solve, express, or adhere to them.

We did not get very far trying to find evidence of the marginalized concept in the mainstream, for lack of time.