I was lucky enough to be at Reboot 10, back at the end of June. I gave a prototype talk working through some ideas I've been thinking about for a while (stuff that I started to work at with my Everything I know about Programming I learnt from Typography talk at the first BarCamp London). The talk was called Craft & Process, and was essentially a braindump and not a real talk - I had a bunch of sketchy notes for an overall structure and talked my way from the start of the notes to the end...
The central idea I've been looking at is that one of the main ways we think about building software and, by extension, all the aspects of applications for the web, is wrong: building software and web apps as an essentially industrial process, managed as if it were mass manufacture, with an underlying assumption that the work involved is repeatable and well-defined. My assertion is that it's actually more like a craft process: that the work is generally unique, and heavily defined by context.
I recorded the audio of the talk. Unfortunately it's not the greatest since I was just using the built-in microphone on my MacBook, but it's listenable. You can grab the audio from the link below (and your newsreader should recognise it as an enclosure).
It's about an hour long, and one of the main things I've noticed is that I was trying to cover far too much ground. There're probably at least two decent talk ideas hiding in there, which I'm looking at developing into proper talks. Hopefully, you'll find it interesting. Please do email me (matt at this domain) if you've got comments or queries.
I made notes on what happens during it, with links out to things I mentioned, and which address areas where I didn't come across in the way I meant to.
02:50 - Vertically separated stacks of people
Here I'm talking about highly-specialised people grouped by role who don't (or don't get) to talk much to people from other disciplines, the classic role silos in which. I'm not sure if I should have said 'horizontally-separated' instead, but hey.
07:48 - Michael Harvey
He's a type designer and letterer who, among other things, is a renowned carver of letters in stone. I was using him as an example of someone with great depth of skill drawn from long experience. Here's his bio on Fonts.com.
09:10 - Limitations of craft
I really need a better example here: time for more research, I think.
10:26 - DTP
For more on this, see my dissertation: Typography and electronic document specification: An investigation
14:26 - 'Academic surveys'
I was thinking particularly of this paper by Alison Black when I said that Visible planning on paper and on screen: The impact of working medium on decision-making by novice graphic designers
14:30 - Paul Stiff's paper 'Instructing the printer: what specification tells about typographic designing'
This fantastic paper is in Typography Papers 1, from 1996. You can't buy it anymore, and all web references to it seem to have vanished, which is annoying. You might be able to track down a copy in a library. Its ISBN is 0 7049 1120 5. If you're in London and you ask nicely, I might be able to lend you my copy.
It's worth clarifying what I mean when I say that the chief product of the design process was not an object, but a specification. Before DTP, if you were designing for commercial print then you would submit a specification to the printer. If you were designing a book then you'd produce a series of layouts which showed the main features of the design. These layouts wouldn't amount to more than a few pages worth of material. The printer would use these to infer how a manuscript should be laid out, and in the ideal world the specification would cover enough variations that the printer could easily produce a printed object that conformed to the designer's idea.
15:29 - Grice's maxims
Grice's maxims of conversation. These maxims get applied by Paul Stiff to typographic specification, positing the specification as a dialogue between typographer and printer:
Under the third category of 'relation' is the maxim: 'Be relevant.' In other words, don't say unnecessary or inappropriate things; for example, don't specify trimmed paper sizes or inks to the compositor, or word spaces to the press operator.
23:25 - The Chicken Sexer
Oh, good grief, where do you start with the Chicken Sexer? At dConstruct 2007, Jared Spool presented. One of his arguments was about designers being unable to explain how they know what they know. Start at slide 11 of The Dawning of the Age of Experience. I call this the savant fallacy. The main problem I have with it is the idea that designers (in this case) absorb knowledge and develop skill by some analogue of osmosis and cannot explain how they know what they know, or why they make the choices they make. I've encountered a lot of this in graphic design too, where this studied inarticulacy is often some kind of perverse badge of honour - almost as if you can't be a proper rock star designer if you're able to actually talk about how you work, rather than just presenting results.
This is a kind of gnosticism, which allows the designer to avoid justifying how and why they did what they did, and appeal to a kind of special revelation instead, which also serves to keep you separate from the people you're working for - both clients and users. I think that you can talk about your work. You can talk about a project, and what happened along the way: where the problems were, what did and didn't work, where the breakthroughs came. You can, in short, show your working.
24:30 - Literate Programming
Ah, Donald Knuth. Wikipedia's Literate programming page is a good place to start. Actually, I had TeX pinned as being earlier than it really was, but I don't think it matters particularly to what I was saying.
26:30 - Norman Potter & Anthony Froshaug
Potter, especially, is a hero of mine, but they're both fantastic examples of engaged practitioners: designers who took control of the whole process of making, from design to manufacture: Potter with his furniture workshop in Wiltshire and Froshaug with his printing workshop in Cornwall. Both looked to see what evolving technology and experience could offer them, both in terms of how they worked and what they could make.
30:30 - Stitch 'n Bitch
The Stitch 'n Bitch Wikipedia page seems to be the best starting point. While the internet has helped radically change how social knitting groups form and meet, I don't think they've radically changed the practice and techniques of knitting. I guess you could argue about stuff like yarns made from plastic bags, but I think that their emphasis (as 'movements') has been the social aspects.
31:20 - Chief Programmer teams
I think I'd taken something I was reading in Fred Brooks' Mythical Man Month and read something slightly different into it: the Chief Programmer Team pages at everything2 and Construx, but it's still interesting: small inter-disciplinary teams, with a single leader who manages and writes...
34.50 - Specialisation is for insects
It's a Heinlein quote, taken from his 1973 novel Time Enough For Love. (Also, rendered as an illuminated manuscript.)
A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.
I was being slightly facetious with this: I certainly don't think that people with specialized skills are pointless, and I certainly don't think that one person can be good at everything. What I've found is that encouraging specialisms with impermeable boundaries, so that someone isn't supposed to know about visual design and HTML/CSS, or HTML and programming, is a very dangerous place to go: it encourages the worst kinds of professional disrespect: the mutterings of 'oh, they're just an [insert profession here], they can't understand this problem...', and people in one silo requesting totally inappropriate things for people in other silos. It blinds you to the insights that working from a slightly different angle give you, and it prevents anyone having an accurate mental model of a system.
That's what I was complaining about, not the very existence of information architects, or web designers who can't work a database.
35.10 - In which I ask a bad rhetorical question as if it were a real question, and ask it badly
My point was that supposed to be that exciting new web products are almost never built by enormous discipline-siloed teams. They may well become something which is run and expanded by a very large organisation, but the best examples of new products come from small, multi-disciplinary, teams. I guess I could have just said that instead of posing a rhetorical question and expecting people to answer it, like a smug idiot. Sorry.