In any task that requires understanding, we will always find at least one cognitive atom'. A cognitive atom is a part of the problem that can only be adequately treated by loading up its elements, features, signs, whatever into the mind of a single mapper and getting the best result possible. The wordadequate' is important here - there are a whole bunch of problems that given unlimited resources could be tackled slapdash, but need thinking about in the real world. For example, any bunch of idiots could pull off the set changes needed on the stage of a big musical show, given several weeks to do it. Doing the same thing in the time it takes the leading lady to sing a melancholy song under a single spotlight takes a logistical genius.
Experienced project planners discover that recognizing and managing the cognitive atoms within a project is a crucial early step in gaining control. First, we must recognize the cognitive atoms. There is a relationship between the system architecture and the cognitive atoms it contains - the architect will have to use intuition and experience to identify solvable but as yet unsolved problems. The problems the architect believes can be solved during development will influence the design, because nobody wants to design an architecture that is not implementable!
The architect can, therefore, move the boundaries of the cognitive atoms around somewhat. For example, in a data mining system, practical combinatorial problems might be concentrated in the database design, or in the higher level application logic. The correct identification of the cognitive atoms will control both the architecture and the work packages devolved to the team members. Each atom must be given to one person or subgroup to kick around, but they may find themselves working on more than one part of the system to solve their problem. The parts must, therefore, be well layered so that modules do not turn into time wasted battles. Identifying atoms usually requires balancing time, space, comms, risk, team skills, portability, development time, and all of this must be done with proposed atoms for which solvability is not certain. The architect must, therefore, be able to see the heart of the problem and express, at least in his or her own head, the nature of the trade-off options. It is quite possible to be able to recognize a set of clearly seen trade-offs that it is very hard to express to another without the same mapper ability to see the structure. Serialising a mental model is always difficult because we do not think in technical papers that we download like ftp transfers.
When identifying cognitive atoms it is important to avoid being confused by a specific fallacy that one sees over and over again. It is often possible to keep breaking atoms into smaller ones without much thought, and thus reach code level without much effort. When such reductions reach implementation, however, all turns to chaos. The real problems haven't gone away, they've just been squeezed down into ugly subsystem APIs, performance problems, fragility and the like. The boundaries of the cognitive atoms have been squeezed smaller and smaller, until... Pop! They re-appear around the whole system itself! The doctrine of simplistic step-wise refinement without regular reality checks and rigorous attempts to falsify the design has been responsible for a great many tragedies, involving wasting most of the time budget on attempting to do the actual design work by open-house informal acrimony, followed by desperate kludging attempts.
The reduction of cognitive atom boundaries can be cyclic, and the skilled architect will pick the right place for them, whether that is high level, low level or in between. Some initial studies can be a huge, single cognitive atom, that one just has to hand to a trusted worker and say `Try to sort this mess out please!'
By definition, we don't know how to best approach a cognitive atom. If we did, it wouldn't be an atom. So it follows that it cannot be planned on a project planning Gantt chart in terms of subgoals. It must be entered as a single task, and the duration must be guessed at. Experienced mappers get pretty good at guessing, but they cannot explain why the problem smells like a two day one, a week one, a six month one. Therefore there is little point arguing with someone who has given their best guess. The fear of the subsequent argument is an important factor that often prevents mappers engaging their intuitive skills, and giving the numbers that are needed for project planning.
The upside of this is that once a cognitive atom fissions, the worker can usually lay out a very detailed set of task descriptions based on a solid understanding of what has to be done. Therefore many projects should plan to update their Gantt charts as the cognitive atoms fission. We suggest that the high proportion of projects that attempt to Gantt everything on day one indicates the pervasiveness of the production line model. The programmers working under such Gantt charts cannot be benefiting from the intelligent management of cognitive atoms. Instead of opening their minds to the problems to be solved, they will be arguing about whether or not they are any good at their jobs and being `put under pressure' as if it is possible to make someone think more clearly by belittling them. This is stressful and counter-productive.
Copyright (c) Alan G Carter and Colston Sanger 1997
Top comments (0)