User talk:Hans
At the Teacher Jam last night, we inadvertently provided a great example of the wrong way to design software. One of the wrong ways, anyway, and I think probably one of the wrongest ways.
When, as a user, you encounter a program, what you see is the interface. Like the introduction to a book, it's the last thing that was done. It's what you see first, but not where the author started. In fact the author couldn't have started there, because the book didn't exist.
Software is in many ways similar. It can begin in many ways. Maybe even as a sketch of an interface. But that's such a poor way to design that I don't know any good programmer who does it. No matter how simple it seems, the design of a program is neither easy nor obvious. There's a prevalent fiction that one begins with a specification and that the program is the correct implementation of that. But unless your only experience with design is paint by numbers, you know that's not how things really work. I like to cook, and do it a lot, and I don't think it's ever occurred to me to start with an idea of how the food should look. Given the way I live, mostly I look to see what I've got and then try to imagine what I could do with it- based of course on all kinds of things, previous experience, intuition, something I had last week that someone else made, ... And quite frequently what I end up with isn't what I thought I was going to make. Unless it's my mother's potato salad, which follows at least a well-known template. Now I know a lot of people are more regular in their habits, and follow recipes. But whence the recipe? Someone, sometime, invented it, and not by either describing first what it would look like or, like an algorithm, the series of steps to get from ingredients to the table. It takes backtracking, imagination, sometimes with unfortunate consequences, experimentation ... and not just because it isn't always easy to get what you want right off, but because, often, you find out what you want in the process of trying to get it - a different 'it' of course.
I can certainly write a program straight out, if it's clear to me what I want to do and it's close to something I've already done. Of course I try to avoid doing that because it's not very interesting, and besides, in programming the leftovers are just as good as the original, so I just serve up old code. But it's not that way I write anything serious. Then I start with some idea of what I'm trying to do, and usually some notion of what might be a good way to do it, but what comes out has generally has mutated in all kinds of ways. This is the case even where the program has pretty tight constraints. There's always more than one way to do it, and the first you try is rarely what works best in the end.
So why don't we all think a bit about how we do the things we are good at, the creative and productive things, and see if this description fits at all. The problem isn't that, as a programmer, I don't think other people can tell me much that's helpful about how to write programs. But what they can contribute isn't the design, either the logical design or the interface design. The logical design can be complex, can depend on all kinds of things non-programmer's can't know, because they're particular to the language, or memory or computational cycles available, or to the demands of style and elegance, and the programmer is the best judge of all that. But the user interface - what you see, as a user, when you run the program - if anything - isn't something you either cook up in advance or toss on at the end, not at least if you're serious about your work. It depends on the problem, as it's come to be implemented, and on the audience, and the resources, and on the principles of design that such as Edward Tufte tries to discover, and, like the rest of the program, emerges from experimentation and testing as well as taste and imagination.
At this point I think I owe everyone who came last night an apology. I should have said all this then, rather than watch a lot of people waste their time in something that I knew was a waste of time. Not the ideas - ideas are always worth thinking about. But the notion that any kind of useable software can come from a process of design that begins with a detailed description of an interface, in isolation from the discovery of what the program will really do, or how children will in fact interact with it, or even whether it will fit on the screen. There's a discipline for doing this, and you are no more likely to get it right by instinct than you are to design a good laptop by first deciding how you want it to look.
