Verbs and Nouns: Designing a Design

(Via the frequently delightful but often scatological Lolbrary.)

We have a very bad habit in Computing of ‘verbing the noun’, where we take a perfectly good noun and repurpose it as a verb. If, in the last few weeks, you’ve googled, face booked, photoshopped or IMed, then you know what I mean. (Coining new words like this, often genericised trademarks, is not new, as anyone who has hoovered the rug will tell you!) In some cases, we use the same word for the action (to design) as we do for the product (a design) and, especially in the case of design, this can cause trouble because it becomes very easy to ask someone for the product when what you want is the process.

Now, I realise that I do enjoy linguistic shenanigans (anyone who plays with which syllable to stress when saying interstices is spending too much time thinking about language) but this is not some syntactic mumbo jumbo, this is a genuine concern. If I ask a student to submit a design for their program, then I am usually assuming that the artefact submitted will be the product of the design process. However, I have to realise that a student must understand what the design process actually is in order for my instruction (give me a design) to be mapped into the correct action (undertake the design process). We’ve collected a lot of first-year student reflections on design and it is becoming increasingly apparent that there is not a clear link between the verb and noun forms of this very simple word. We can now start to understand why a student would feel frustrated if, when asked for a design, they submit what is effectively a re-writing of their final written program on a separate document with some arrows and we turn around and tell them that “this is not a design”. Well, what did we want? The student has given us a document with stuff on it and the word ‘design’ at the top – what did we expect?

The same is, more subtly, true of the word program. After all the practise of programming is the production of programs (and the consumption and elimination of problems but that’s another post). Hence, when I ask a student for a program, or for a solution, I am often not explicitly placing the written instructions into a form that clearly elucidates the process and, as a result, I may miss important constructive steps that could assist the student in understanding and applying the process.

Let’s face it, if you don’t know what you’re doing, or don’t understand that there is a process to follow (the verb form), then any instructions I give you “Make sure you use diagrams”, “clearly label your variables”, “use UML” are going to be perceived in a way that is grounded in the final product, not the steps along the way. If I can use neo-Piagetian terminology briefly, then we’re looking at the magical thinking that we’d normally associate with the pre-operational stage. Not only is the knowledge not sinking in but we will engender a cargo-cult like inclusion of features that are found in the artefact but have no connection back to the process at all. We have potentially reached the unpleasant point where students now think that we are deliberately, or unfairly, ignoring the work that they provided in direct accordance with our instructions!

Anyone who has ever looked at a design with the steady sinking feeling that comes from reading poorly translated programming language, marked with superfluous arrows and dogged, yet unnecessary, underlining of the obvious, will probably be feeling a pang of empathy at the moment.

So what to do? How do we address this problem? The first step is to remember how fiendishly ambiguous language actually is (if English were easy, we wouldn’t need constrained and artificial programming languages to unambiguously assign meaning for computers) and be precise about the separation between the process and the product. The design process, which we provide guidance and steps for, will produce a design document. We are luckier in programming because while you can program and produce a program, you cannot produce a programming! In this case, the clarification is that you have assigned a programming task in order to produce a program. In our heads, we are always clear about what we mean but it is still amazing how often we can resort to asking for a product that is the final stage of a long and difficult process, which we are intending to teach, without realising that we are describing the desirable characteristics of the end point without considering the road that must be travelled!

On reviewing my own teaching, I’m intending to add more process-based instructions, on the grounds that encouraging a certain behaviour in the production process is more likely to lead to a successful product, than specifying an end product and hoping that the path taken is the ‘right’ one. This isn’t exactly rocket science, it’s well established in how we should be constructing these activities, but it does require the educator to keep a clear head on whether we are discussing the product or process.

When a student has established enough understanding, and hopefully all will by the end of the process, then I can ease back on these linguistic scaffolds and expect a little more “this means that” in their everyday activity, but at the start of the educational process, it is probably better if I always try consider how I specify these potentially ambiguous noun/verb pairs. After all, if a student could pick this up by osmosis or plain exposure to the final product (or even by neurolinguistic programming through the mere mention of the name of the artefact) then I would be thoroughly unnecessary as an educator!

I strive to reduce ambiguity and this requires me to think, very carefully, about how my words are read by students who are not even in the foothills of mastery. Reorienting my own thinking to clearly separate product from process, and labelling and treating each clearly and separately, is an important reminder to me of how easy it is to confuse students.