BT

Holding a Program in Your Head

by Kurt Christensen on Oct 19, 2007 |
In a recent essay titled "Holding a Program in Your Head", Paul Graham - essayist, Lisp hacker, and the creator of Yahoo! Stores - argues that "your code is your understanding of the problem you're exploring. So it's only when you have your code in your head that you really understand the problem." Unfortunately, as every programmer knows, this is easier said than done:
It's not easy to get a program into your head. If you leave a project for a few months, it can take days to really understand it again when you return to it. Even when you're actively working on a program it can take half an hour to load into your head when you start work each day. And that's in the best case. Ordinary programmers working in typical office conditions never enter this mode. Or to put it more dramatically, ordinary programmers working in typical office conditions never really understand the problems they're solving.
So what can a developer do to get a program loaded into their head? Graham offers eight suggestions:
  1. Avoid distractions
  2. Work in long stretches
  3. Use succinct languages
  4. Keep rewriting your program
  5. Write re-readable code
  6. Work in small groups
  7. Don't have multiple people editing the same piece of code
  8. Start small
Agile processes and practices can be viewed as a mapping of what happens organically in a successful startup company to what can possibly be done within a large organization. As a partner of the seed investment firm Y Combinator, Paul Graham targets most of his advice towards small startup companies, and so the question becomes which of these best practices map to agile practices. Certainly most agile developers are accustomed to writing re-readable code, continually refactoring, working in small groups, and starting with the smallest thing that provides real value. And many agile developers are increasingly moving towards more powerful languages such as Ruby, Erlang, Haskell, or even Common Lisp.

But what about those suggestions that don't easily map to agile practices? (1) and (2) go hand-in-hand, and some would argue that working in a shared lab space is the antithesis of avoiding distractions. Another common agile practice is shared ownership of code, contradicting (7). So do the agilists have it wrong? Or does the conflict between these recommended practices reflect the unavoidable differences between working for a small company and working for a large company?

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Mental Models, abstraction and communication by Paul Oldfield

Well, I was all prepared to disagree, but I like a lot of what is said.

My first and most important point is that this approach does not scale. If you want an approach that scales, you need to be able to have one or more levels of abstractions, you need to be able to separate the concerns and hide the details behind interfaces. Your mental model will not be in code.

Let's go through some of the points he raises.

Avoid Distractions: definitely not very agile. I favour Alistair Cockburn's description of 'osmotic communications' - one has a subliminal awareness of what's going on in the rest of the team. This isn't a distraction until it needs to be; until something comes up that needs your input.

Work in long stretches: I favour sessions about 90 minutes long. I really like and agree with Paul G's point that time away from a problem can give one's subconscious a chance to solve it. To me, wanting longer sessions is a smell; it says to me that the mental models are not adequate. For me, a good model is an aide-memoir; one glance at the model and the whole thinking behind it comes rushing back into my mind. Sure, if I haven't solved a problem then it takes a while to get back into the train of thought - but that tells me the problem is not being cut down into small enough chunks.

Succinct Languages: Agreed.
Keep re-writing: Only to improve the code.
Re-readable code: Essential.
Work in small groups: I favour group ownership of the code. This scales better and means that you never lose the ability to do all-encompassing re-designs.

Several People Editing: His suggestion here is definitely not agile. It sounds quite dysfunctional. The team should be working to a shared vision.

Start Small: Agreed, but the problem he addresses is better solved by developing abstract models that keep the big picture in mind, while delving into the detail one area at a time.

In general, these practices talk to me of poor team communication, poor abstract modelling. If you're listening, Paul, take this as hints as to how you might improve, not as destructive criticism.

Re: Mental Models, abstraction and communication by Kurt Christensen

As always, thanks for your thoughtful comments. I like most of what Paul Graham has to say, which is why I always enjoy trying to map it to practicing agile in a large IT shop. It works more often than may be obvious, but not always.

Which brings me to your comments. I agree with what you said, but I don't think it's because he's wrong, I simply think it's because he's addressing groups of 2 or 3 incredibly talented developers working on apps for startup companies. In that case, there are different forces at work, and - more importantly - the codebases are new and small. As an example, Reddit was built on top of web.py which is all of a thousand lines of Python code. Contrast that with one of my current clients, which has about 2 GB of source code feeding into a single product suite. I don't think the values in those two organizations necessarily differ, but the practices certainly will.

Re: Mental Models, abstraction and communication by Paul Oldfield

Hi, Kurt.

Yes, I'm all in favour of applying what works best in the given circumstances. I don't subscribe to the view that there are *any* universally best practices. On the other hand, a successful start-up will grow into a different set of circumstances. It makes sense to be aware of the problems that will come to the surface when that happens.

Re: Mental Models, abstraction and communication by Deborah Hartmann

> Avoid Distractions

I've worked in Agile environments where "shared workspace" led to distractions, because of:

- poor inter-team boundaries (low walls, with team A overhearing team B's discussions: a real annoyance because team B's "noise" didn't contribute to team A's work, and vice-versa). This was resolved by adding a full wall in that location.

- poor teamroom flow (everyone sitting facing *out* at the boundary wall of the team room. Every conversation was shouted across the room). This was resolved by moving the tables away from the walls, to create smaller "pools" of conversation.

In both cases, space design contributed to chaos, rather than enhancing it. As long as the space itself is agile (susceptible to change, as needed) this just becomes part of the continuous improvement cycle.

Re: Mental Models, abstraction and communication by Paul Oldfield

Agreed. We want to distinguish between unproductive distractions and productive distractions. I wrote about productive distractions several years ago:
<www.aptprocess.com/whitepapers/risk/RiskToPatte...>
There's also a page on that site titled "Interrupts Unjam Blocking" (the name says it all!).
We usually consider these ways of thinking to be already embedded in the ways an agile team works.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

5 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT