One of the things that I find myself thinking about a lot on projects is memory.
One of my favourite parts of Grady Booch’s book Object Oriented Analysis and Design with Applications is the part at the beginning where he discusses the cognitive psych theories that the brain is only capable of holding seven plus or minus two things at any given time. Booch argued that good object-oriented design allowed one to gracefully abstract a system so that one could be looking at seven small, detailed parts of the system, or abstract that up to look at seven high-level components.
In fact, many of the earliest writers about object-oriented technology talked about it as a tool for addressing problems of memory and understanding. According to the classic argument, at around 500,000 lines of code, applications written in structured programming technologies are no longer comprehensible, because there’s too much detail for the brain to wrap itself around.
I think, therefore, that OO came in to existence because of an explicit acknowledgement that people can only remember so much.
I think that the same concerns about memory and abstraction play out in some of the agile practises. For example, when we work on one story at a time, we have one high-level thing that we decompose into a number of smaller tasks. A single user story seems to be the right size of thing for developers to wrap their heads around. And a list of about seven tasks seems like an ideal number of things that still allow people to understand them. I hear conversations where people say, “we don’t need to worry about that in this task; we’ll worry about that when we hit that other task.” Which suggests to me that people are keep a relatively clear picture of the list in their heads.
Past experience has shown us that the more tasks a story has, the more likely it is to fall victim to the “fuzz factor” — the problem that ambiguity slips in to the task definitions, and that mistakes will slip in to the implementation. Usually these mistakes show up as people say things like “wait, what task was supposed to handle the glue between component X and component Y” or “we don’t have a task to handle this particular requirement”. We still often refer to size in the story point numbers — 1, 2, 3. For us, size 3 stories set off warning bells because we suspect that the fuzz factor will bite us.
Speaking only for myself, I believe in agile methodologies because of its project management benefits. Before I worked in agile environments, I’ve seen a majority of projects burdened by cost and schedule overruns; I haven’t seen that on agile projects.
And I think that the way OO breaks down and decomposes monster applications, agile planning breaks down and decomposes monster Gantt charts. I can abstract nicely: tasks abstract up to stories, which abstract up to a list of stories in this 2-week development cycle, which abstract up to 6-week iterations, and on and on and on.