Hard Intangibles - Update

I’ve gained some clarity recently about what the hard intangibles project consists of. In short, I’m fascinated by the growing gap between our innate capacities and the intangible world we’re building.

I cut my teeth on the question of mental models used in spectrum policy and cognitive radio research (PDF). I’m now preparing to survey the literature for evidence that people find working with digital artifacts (computers, software, web sites, social network spaces, etc.) difficult because of the differences between the dirt world and the digital world.

The medium term goal is to answer the question “Why is (parallel) programming hard?” The dominant conversations about program hardness today are either technical (e.g. complexity classes) or social (e.g. “wicked problems”). I’m interested in a third perspective: cognitive hardness, which comes in two flavors. Bruce Schneier recently published a good paper on how cognitive biases can affect the security of computer systems. I’m more interested in cognitive capacity rather than cognitive biases, e.g. the number of independent variables we can keep in our head at the same time. These limitations are presumably at the root of folklore about the right (small) number of arguments in function calls, and the number of modules in a project. They presumably also guide programmer’s preferences for simple organizing principles like lists and trees (rather than, say, semi-lattices).

I’m not dismissing social issues; it’s clear that they are at the root of many failures in software projects. However, these problems are by no means unique to programming. I believe that the intangibility and flexibility of software presents a qualitatively different cognitive challenge to most (all?) previous kinds of engineering.

It gets even harder and more important as we turn to parallel programming. Limitations on human working memory will make grasping parallel programs particularly difficult. Programming tools are surely part of the solution, but tools have typically automated and accelerated activities that humans have already mastered. It's an open question whether we can conceive of 1000-core parallel processing sufficiently well to create tools.

The work I want to do on programming has a number of threads:

1. Review neuroscience and cog psych literature for clues about limitations that would apply to programming
2. Interview programmers to understand what they find difficult, and tie it to #1
3. Do some psych (and ideally neuro) experiments on programmers to validate hypotheses
4. Evaluate current programming methods and tools against the cognitive limitations we’ve identified to find matches and gaps
5. Identify most promising areas for improving programming by taking cognitive limitations into account

The answers on why is programming hard are key, I believe, because they will probably generalize to other hard intangibles, like law, system planning, and international relations.