Read the Humanities

From WikiContent

Jump to: navigation, search

In all but the smallest development project people work with people to achieve the goal. In all but the most abstracted field of research people write software for the purpose of supporting someone in some goal of theirs.

People write software with people for people. It's a people business.

Unfortunately the education and training of a programmer tends not to equip anyone to deal particularly well with people. In fact, the tools and techniques taught to programmers too often equip them very poorly in dealing with the people they work for and with. The real irony of the situation is that merely being a person doesn't grant any particular insight into — nor ability to deal well with — other people.

The most critical interaction that programmers have with the people for whom software is written is in understanding what those people want. The only way to do this is to ask them them to tell you and the education of a programmer can lay some particular traps which make that difficult. Programmers also collaborate closely with one another, often in very complex ways in very complicated settings. That's hard. Luckily there is an entire field of study that can help us.

For example, Ludwig Wittgenstein makes a very good case in the Philosophical Investigations (and elsewhere) that the language we use to speak to one another (any languages) is not, and cannot be, a serialization format for getting a thought or idea or picture out of one person's head and into another's. Already we should be on our guard against misunderstanding when we supposedly "gather requirements." Wittgenstein also shows that our ability to understand one another at all does not arise from shared definitions, it arises from a shared experience, from a form of life. This may be one reason why programmers who are steeped in their problem domain tend to do better than those who stand apart from it.

Lakoff and Johnson present us with a catalogue of Metaphors We Live By, suggesting that our language is largely governed by metaphor and that these offer an insight into the nature of our thoughts and understanding of the world in which we live. Even concrete seeming terms like cash flow, which we might encounter in talking about a financial system, can be seen as metaphorical. Here the metaphor is that "money is a liquid." How does that metaphor influence the way we think about systems that handle money? As technologists, too, we might talk about layers in a stack of protocols with some being high level and some low level. This is powerfully metaphorical language, and the metaphor exposes our thinking about the structure of the systems we build. It can also mark a lazy habit of thought that we might benefit from breaking form time to time.

Martin Heidegger studied very closely ways that people experience the use of tools. Programmers build and use tools, we think about and create and modify and recreate tools all the time. Tools are objects of interest to us. But for the users of tools, as Heiddeger shows in Being and Time, the tool becomes an invisible, unregarded thing understood only in use. For users, tools only become objects of interest when they don't work. This difference in emphasis is worth bearing in mind whenever usability is under discussion.

Eleanor Rosch overturned the Aristotelean model of the categories by which we organize our understanding of the world. When programmers ask users about their desires for a system we tend to ask, explicitly or implicitly, for definitions built out of predicates. This is very convenient for us, the terms in the predicates can very easily become attributes on a class or columns in a database table. These sorts of category are crisp, and disjoint and tidy. Unfortunately, as Rosch showed in Natural Categories and later works, that just isn't how people in general understand the world. They understand it in ways that are based on examples. Some examples, the so-called prototypes, are better than others and so the resulting categories are fuzzy, they overlap, they can have rich internal structure. In so far as we insist on Aristotelean answers we can't ask users the right questions about their world.

by Keith Braithwaite

This work is licensed under a Creative Commons Attribution 3


Back to 97 Things Every Programmer Should Know home page

Personal tools