Physical Cues In Software Development

This is a really bad title for the page ... can anyone who thinks of a better one please create the page and move this stuff there. Ta.

Rather than try to explain what I mean by 'physical cues', here are some examples:

CRC cards: Limited in size. If you can't fit all the responsibilities for a particular class on one card, maybe you need to create a new class and distribute the responsibilities.

Smalltalk class browser: Unless you work with a 28" monitor and 8 point font, the method window in a class browser only allows you to write 5-12 lines of code before it is LongEnoughToForceAnElevatorIntoTheScrollbar (I do a lot of work on a laptop which only allows 5). Don't write methods that don't fit in the window; split into several smaller methods that do.

Smalltalk coding style: RonJeffries XP practices has a section on using a consistent coding style. If you use his standard coding style and the method looks ugly, maybe the method needs refactoring rather than the style needs changing.

What made me think about this was a workshop I did last week. We were building an example distributed system and did some CRC to get basic classes. We then laid them out on the floor and wanted to link up classes that collaborated with each other to see if there were any natural distribution boundaries. We didn't have any string or tape so we ended up using plastic spoons laid end to end(pretty good choice actually because spoons are directional when laid flat). Thing was we had a limited amount of spoons so, when we ran out, we really had to cut back on extraneous collaborations to conserve our spoon supply.

So I guess this is all about physical constraints in the development/design of software that translate into real constraints in the software:

Methods need to be simple and readable if they are to be understandable and changeable. Any method longer than, say, 8 lines is going to be complex and hard to understand. The limited physical size of the method window pushes us towards writing short, readable (if you're not a confirmed C hacker - some of these guys can fit more into 8 lines than I get into 3 or 4 classes), understandable methods.

In a highly distributed system you need to minimise the inter-object interactions because these are expensive in terms of performance and robustness (more chance an interaction will fail if it is over the network so more excpetion handling, etc., required). A limited supply of spoons really made us think about minimising these expensive interactions.

At least, an interesting aside; in the deepest darkest recesses of my mind I wonder whether there is some tie in with the NatureOfOrder. Any other examples?

[It does have an ironic/dialectical tie-in with the OriginsOfOrder. -- SteveWitham]

-- PaulDyson

Maybe PhysicalCueAsGuide? or PhysicalCueAsReminder?

I really like well-chosen cue. The key for me is that they shift some responsibility for doing the right thing from the cerebral level to the visceral. That does two things. First, it reduces the need to think. Not that I'm against thinking! But I would rather reserve thinking for the things that truly require it and do things that should always be done a certain way automatically. An analogy: I always wear a seatbelt. But I never think about it because I've made it a habit.

[Civilization advances by extending the number of important operations which we can perform without thinking about them. Operations of thought are cavalry charges in a battle – they are limited in number, they require fresh horses, and must only be made at decisive moments. -- Alfred North Whitehead]

The second thing it does is give you immediate feedback that is hard to ignore. (At least, it's hard for me to ignore. I have a low tolerance for tedium. Does this work for everyone?) Working with Java, if a class is too big, I'm scrolling around too much. It feels like biking into a headwind – there's a noticeable drag limiting my pace. That tells me the class is too big before my brain figures it out. At that point, I typically jump to the bottom of the file, look in horror at the line number, then scroll up through the file noticing 'clumps' of methods.

When I first encountered such things, I really hated them. The problem was that they were too often presented with irrelevant justification or none at all. People need to understand the value of the cue to buy into it.

-- KielHodges

Maybe we term this page the PhysicsOfSoftware??

Ever noticed nobody prints Smalltalk code, while lots of people print C code? In the C world a function over a page long is considered poor style, just as in the Smalltalk world a method over 8 lines.

If these rules of thumb on class/method sizes are a result of physical display size, what will be the effect when we all use 48" thin panel LCD displays in five years? -- AlanWostenberg

We'll all be force to write assembler so that the routines are the proper length! -- KielHodges

Thanks for this great page, Paul. I'm also very interested in the theme and like your examples. I use CRC cards, use cases and lo-fi prototyping as examples of people working from examples and using motor cognition; your other examples are new and intriguing. Like the spoons. Forcing ideas to fit into a small space does good things for the ideas (and the thinkers). Cheers -- AlistairCockburn

Surely DonaldNorman's notion of Affordance is relevant. Roughly (haven't touched this stuff in a long time), a physical object affords certain types of activity and designers should take this into account. For example, the handle on the push side of a door should be flat so that it's obvious you shouldn't pull it. The affordances of a CRC card are that there's little room for text and you're obviously going to bin it - so don't sweat the detail too much. -- SteveFreeman

I also thought of DonaldNorman when I hit this page specifically the concept of KnowledgeInTheWorld? that he talks of in POET. It makes a lot of sense to push some of the cognitive burden out of short-term memory and onto the world, particularly with complex ideas that need to be shared and rearranged by collaboration. -- LarryPrice

[See TheDesignOfEverydayThings book on the PsychologyOfEverydayThings page.]

Hmm, just a thought experiment: What would happen if the length of Wiki pages was technically restricted to a certain maximum, say, to 50 lines?

-- FalkBruegmann (and others)

It should be noted that a significant number of Wiki visitors cannot edit a page larger than 32K. This has altered the development of several pages.

See http://www.abuzz.com/ for an example of a very limited input interface. The input text area is 28 columns x 6 rows = 168 characters. (There is a scrollbar, so you aren't limited in length.) Maybe it was inspired by the Vic-20 which had a 23 (22?) column screen?

Reminds me a lot of the original ForthLanguage, which restricted functions to one physical screen display. (The editor and disk system could only read and write numbered single-page screen images, making it hard to work with anything larger.) -- JeffGrigg

Not even a full physical screen. 16 lines of 64 characters each. Sometimes one can use cheats to continue compiling on the next screen. There are still many vocal Forth users (including its inventor) who believe blocks are far superior to files.

On the other hand, the Forth model can lead to people filling up the lines so as to cram more into the screen and leaving out comments so as to avoid wasting disk space. Back when all you had was a single 8-inch floppy this this was a bigger deal, but I saw some awful code back in the early 80s.

"Shadow blocks" deal with this. You put your code in even blocks and the commentary for it odd blocks. Many block editors have a key command to toggle quickly between a code block and its shadow.

EditText of this page (last edited October 11, 2009) or FindPage with title or text search