Holding a Program in One's Head (2007)

I have been known to do that. It is great for writing an initial block of code.

It doesn't work so well 6 months later when you're editing that code.

You seem to be in love with the idea that a problem can be understood by decomposing it into sub-problems, and considering them individually.

Where I could agree with you is that a solution to a problem should be understandable in pieces, and then composed out of those pieces. Where I don't agree is that I think piecemeal understanding of the problem is likely to yield suboptimal partitioning of the problem into abstraction pieces. Following your train of thought you will end up with a solution that is locally optimized, but globally inefficient, because the problem was not partitioned correctly. Proper partitioning, I think, requires global understanding of the problem, with enough detail of what matters. The problem with global understanding is that most worthwhile problems do not fit in the head easily, but the solution is that coding pieces of the solution allows a more efficient way of reasoning about the problem, eventually leading to a global, or at least global enough understanding.

In other words, I worry you succumbed to "just design it correctly, and it will work well" fallacy. I call it a fallacy on my own experience, but also on the "Mythical Man-Month" book. I'll give the right quote in a moment.

I might be wrong in how I see your point, but if I am right you will hit some serious problems down the road. I don't think I can convince you now, but it would certainly be worth the effort for you to remember this conversation and think back to it if you do in fact hit the problems.

[EDIT] And here's the promised quote from "The Mythical Man-Month", by Frederick P. Brooks, Jr., 1975, to illustrate the "just design it correctly, and it will work well" fallacy:

---------------

I still remember the jolt I felt in 1958 when I first heard a friend talk about building a program, as opposed to writing one. In a flash he broadened my whole view of the software process. The metaphor shift was powerful, and accurate. Today we understand how like other building processes the construction of software is, and we freely use other elements of the metaphor, such as specifications, assembly of components, and scaffolding.

The building metaphor has outlived its usefulness. It is time to change again. If, as I believe, the conceptual structures we construct today are too complicated to be accurately specified in advance, and too complex to be built faultlessly, then we must take a radically different approach

Let us turn to nature and study complexity in living things,instead of just the dead works of man. Here we find constructswhose complexities thrill us with awe. The brain alone is intri-cate beyond mapping, powerful beyond imitation, rich in diver-sity, self-protecting, and self-renewing. The secret is that it isgrown, not built.So it must be with our software systems. Some years ago Harlan Mills proposed that any software system should be grown by incremental development.

That is, the system should first be made to run, even though it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit it is fleshed out, with the subprograms in turn being developed into actions or calls to empty stubs in the level below.

--------------

Long stretches of uninterrupted thought are required to correctly partition the problem, which is a hard problem as the number of possible partitions is roughly exponential to the number of moving parts. Once the problem is optimally partitioned, understanding the solution is a linear effort. Hence, effort required to understand the problem is not indicative of the effort required to understand the solution. Now, for a new person to understand why this partitioning was preferred to all others requires one to go all the way back, and I worry can never actually be replicated, which is why old software projects often stagnate after the original architects depart.

Olympiad programs are pure algorithms, which I agree are more math intensive than most "normal" programming done today (though I wouldn't dismiss math as "riddles"). But that's my whole point: most problem domains have some mathy parts, whether in the algorithms or from the problem domain. As we reduce the cognitive burden of plumbing and architecture that exists in programming today, these meaty parts will take up a larger portion of the programmers workload. The required skillset will shift somewhat, rather than rewarding the same mental juggling process at a larger scale.

Nice idea, but, sorry, it does not work as well in real life as it does in theory. :-(

In any case, everybody is talking as if holding a program in your head is a huge problem. It really isn't. All it means is that particular individual understands the problem (and the solution) deeply and comprehensively. That sounds like a good thing to me. It is true that communicating that level of understanding can be challenging, which is true of most domains. What is special about software development is the degree to which we attempt to communicate that understanding.

Well, why do we do that? Do we really need to communicate that understanding when it is sitting happily in that developer's head? Instead of moving the mental model from one developer to another, trying to squeeze that rich, internal representation through the band-limited drinking-straw that is the human sensory suite, can we just move the developer himself, mental model and all?

The problem really arises because of all those preconceptions that we have about how team-working and large organizations should function, about how people should be replaceable cogs: jelly-beans that can be discarded at will.

Do you like being a cog?

Do you like working for organizations that treat people that way?

I do not.

Instead of trying to dehumanize our profession, can we not re-humanize it? Instead of talking about re-using code, why do we not talk about re-using developers? Recognizing that developing code is as much about developing knowledge and expertise in the head of the developer as it is about herding electrons through tiny pieces of semiconductor. We should value that learning, that knowledge and expertise, and seek to maximise the return from it, rather than hanging on to the (inappropriate, perverse, and just plain wrong) idea that humans are substitutable parts in a machine.

Write code, yes. Write documentation, yes, but recognize and acknowledge the unavoidable truth that a significant part of your intellectual capital lives, not on pieces of paper, nor on magnetized platters, but inside somebody's head. Consequently, when you seek to maximize the return on your investment, seek to build on your developer's expertise by redeploying him or her to use the same expertise to solve as many related problems as possible.