Programming Vs Designing

There has been some small interest of late in the matter of design. This page is an attempt to share certain epiphanies I have had on the subject. But first, I will address a series of misconceptions about InteractionDesign (henceforth just design on this page) bolstered by AlanCooper's mistaken attempt to try to teach his brand of it, CooperInteractionDesign, to programmers.

Please keep in mind that this applies to all technical experts, even theoretical physicists and mathematicians, not just programmers.

Design is not something that programmers can do. It's not a matter of attitude as commonly believed and it's not a matter of conflict of interest as AlanCooper believes.

[RK rant deleted...]

Nicely written. As a suggestion, one thing you can do to demonstrate the the need (or desire) for sight to the blind is to *demonstrate utility*. Show them what you can do. Demonstrate the power and effectiveness of your capability. This is how any long-lasting new concept becomes known - it's utility and power is demonstrated. If it fails to follow up, it becomes a fad and rapidly fails. Of course, there's a catch-22, assuming that you're correct in all particulars - just as a programmer is brain damaged to the point he's incapable of designing a system, a designer is brain-damaged to the point where he's incapable of implementing the system he's conceived. And since a programmer can't understand it, the designer is incapable of explaining it. This begs the question of how truly powerful the designers mode of thought actually is.

I can conceive of things you can't implement. How's that for power?

Big woop. It's not hard to think of a concept that nobody else understands, or even just to say you can. The power is in realizing that concept.
Spoken like someone who doesn't play with concepts either for fun OR profit. In actual practice, it's exceedingly difficult to come up with meaningful concepts which others can't understand. For instance, most of the ineffables in the old Mystery religions boil down to non-concepts, mere contradictions in terms.
- I've certainly never had any trouble grasping concepts in ancient religions. But I should have been more clear. Claiming that your concepts are ungraspable by the people who need to grasp them is counter-productive when it's not wrong. If your concepts can't be understood then either a) they're not very good or b) you need to learn to communicate better
If as a programmer you aren't interested in people who claim to produce programs you can't implement, then why the hell do you think that as a designer I'm interested in people who merely claim to produce concepts that can't be understood?
- I'm very interested in people who can produce programs I can't implement, if only for the challenge (there is, of course, a wide variety of programs beyond my technical skill). But you haven't described anything like that, only made claims that they can't be understood
- That's because I won't describe them. It's not worth the communications cost for me to describe one of my serious designs to other people for them to implement. And THAT is what makes my designs unimplementable by other people. And even if it were worth the communications cost, there's the issue of control of the resulting product. -- RK
- You realize, of course, that the claim "Others cannot produce what I design, because I won't tell them what it is" is entirely vacuous. You seem to view it as an indictment of programmers that they cannot either a) read your mind, or b) independently come up with the same things as you, and then implement that thing. If anything, it's an indictment of you--if you aren't gonna build it yourself, and you won't describe it so others can build it, then what the hell are you complaining about? That would be like LarryNiven stating that today's engineers are incompetent because they cannot construct RingWorld, so he's not going to bother showing the blueprints he's drawn up. -- ScottJohnson
- Yes, Scott, I know it's vacuous. Exactly as vacuous as "I'm precisely as smart as I think I am". But I do intend to implement it all at some point.

Conceiving of things that cannot be implemented isn't hard; I just conceived of a time machine. That doesn't make me a great designer. :) Many great designs (on paper, or in the mind of the designer) fail precisely because they cannot be implemented. Some designers then blame the implementor(s) for being insufficiently skilled--but there are things which are beyond our (current) ability to build, or build efficiently.

Then there's the whole area of communicating between designers and programmers which can be researched. I note the fact that in 3 or 4 days, I went from not even realizing the existence of a phenomenon that was in principle beyond my experience, to a full-fledged theory of that phenomenon.

Communication is clearly the trouble. And I'd have to say that the burden here is on the designer - you're the one with the grand concept, and you *must* learn how to break it down so that it's realizable. Otherwise it's just handwaving. There remains, of course, the unproven claim that the interface designer actually knows what the hell he's talking about and that the interface he's conceptualizing is worth a damn. The proof is in the pudding, as they say.

You clearly haven't learned a single thing from this page. Nothing you've written makes any sense whatsoever. I can easily invert it:

Communication is clearly the trouble. And I'd have to say that the burden here is on the programmer - you're the one with the software to build, and you *must* learn how to grasp concepts if you're to build worthwhile software. Otherwise your software is just crap. There remains of course, the unproven claim that programmers actually know what the hell they're doing (given the existence of C++, there's plenty of doubt about this issue) and that programmers CAN in principle write good software. The proof is in the pudding, as they say.

Sure. But programmers already *do* create software, and we aren't the ones who're making claims that we can significantly improve the status quo. I can build software without an interaction design. Now, you claim that I can't create *good* software that way. Okay, fine, for the sake of argument. But I can create software. You can conceptualize a design all you want, but you can't realize that design unless you or someone else implements it. If you want me to implement it, then you need to communicate what you want to me in a reasonable way. I certainly don't think this is impossible, nor do I think it's hard, but that's because I don't think that the concepts you envision are out of reach for programmers the way you think they are. Regardless, your position here clearly puts the InteractionDesigner in the drivers seat and the programmers in the code monkey seat, which means the responsibility lies with the designer.

If "creating software" were a worthwhile goal then why not creating designs? No, the only worthwhile goal is to create GOOD software, and that hasn't been met yet.

That last line is a good argument though. But the interaction designer is only a substitute for the customer. If programmers are reduced to code monkeys, then they aren't doing their job. I'd really like it if interaction designers had the initiative but not the entire responsibility, but there are problems that way.

Communicating a design to a programmer is possible but not easy. And even then, it's only possible if the programmer doesn't seek to understand the design in the same way the designer understands it. When the programmer starts to question the design, starts to ask why certain concepts are needed instead of other concepts which they favour, and wants an explanation that doesn't simply regress to other concepts, then you're into real trouble. I'm very, very good so usually I CAN come up with an explanation but this takes massive amounts of effort and is no guarantee that the explanation will be accepted.

Would the programmers be redundant if languages progressed to the point where the interactive design became the program? -- PeterLynch

Languages will never progress to the point where a model becomes the program, nevermind a design.
On the contrary, I think an argument can be made that every language is, in fact, a modeling tool that allows a designer to express a design in terms of symbols which become an executable program. Why shouldn't languages evolve to the point where higher and higher level concepts can be expressed in easier and easier ways? Why shouldn't development environments evolve to the point where modelling, prototyping, and programming merge into a single software modelling activity? The above bullet point, unless qualified with some sort of mathematical proof, sounds like claims that heavier-than-air craft will never fly. -- DaveVoorhis
There are already multiple pages on this wiki about the essential difficulty of programming and its non-automatability. Suffice to say that while you can express one problem in a single problem domain using purely high-level concepts of a language tailored to that single problem domain (spreadsheets are one example), this doesn't mean that you can ever express the whole problem domain using the concepts of the problem domain. No, you need programming concepts for that. This is why a design will never become a program. Now, when talking about a model being a program we're really bickering over details, literally. We're bickering over the level of detail that distinguishes a "model" from a "program". Who's to say that programs in a sufficiently high-level language like Smalltalk aren't models already? XP proponents like to think so. The code is the documentation and all that.

This is the thing that I don't understand: How is it that none of the academics who spend their careers designing yet another compiler for yet another language have come up with a programming language whose source form is an unambiguous graphical model? Clearly, the "unambiguous" part is difficult, since whoever said a picture is worth a thousand words never knew about software. On the other hand, it shouldn't be intractable. It would still need programmers; being a change of tool, not skillset. -- MarcThibault

As an academic who spends a goodly portion of his career designing yet another compiler for yet another language, I have in fact worked on a GraphicalProgrammingLanguage which I released (and then promptly dropped as unviable and uninteresting) at http://tomatoide.sourceforge.net. Therefore, your statement that no academics have come up with a programming language whose source form is an unambiguous graphical model is untrue. Whether or not that source form is better than text, however, is a different issue. -- DaveVoorhis

I stand corrected. The mystery turns to why none have caught on. --mt

That is an essay question, but I can offer a simplistic answer via analogy: Graphical programming languages have not caught on for the same reason that a recipe for spicy chili is given as a series of steps rather than a diagram. Visual programming seems to be an appropriate model for declarative programming, but awkward and unwieldy for imperative programming. Graphical programming has caught on in certain domains, such as LabView's graphical language for defining instrumentation and the shader language in Houdini. -- DaveVoorhis

Humans are good at 2D image manipulation. 3D is a bit harder, but still possible with some training. Add one more dimension and most of us fail miserably. Trying to represent the relationships in real source code in 2 or 3 dimensions is very difficult and the result can be much more confusing than the equivalent text. It's the same problem you run into when trying to visualize a reasonably large wiki. Navigating between different views of a semi-lattice is easier inside our heads than outside. -- EricHodges

"yet another language" - we have great languages already, like the Python family and languages like the Lisp family. Both are good for procedural and OO and even FunctionalProgramming. I would venture to say that the syntactic shape of the language of the future already exists and is in use. What I believe is that we should not be looking for a new language, but for a concept which allows for (almost) all current languages - a concept which could be implemented in all languages. One way of doing that would be to create common use high level language elements and the means to implement these in other languages. The high level elements would be at such a level of abstraction that they could be published in a dictionary. For example, the most common socket communication should be encapsulated in two processes, one for sending and one for receiving, such that application code using comms in any language could use a version of these processes. Delving into my past, I find this example which I used to insulate the application layer from the intricacies of serial and parallel port communication -

  Success = Send.To.Port(Port.Name, Sent.Data, Port.Reply, Wait.Time)
  Received.Data = Get.From.Port(Port.Name, Prompt, Maximum.Length, Wait.Time)
 and a Close process.

-- PeterLynch

Furthermore - (I found this in an old unsent email) - What I would like to see is the set of process definitions and application constructs which allows the "source code" of the program to both act as the definition of the process, and as the eventual compiler input. A middle layer. I reckon this is THE middle layer. Not a layer which lives between different technologies, like Middleware, but a layer which sits between the user and any of the technologies. A layer which enables the user the level of control they now pay the programmer for.

One might say programmers are the only real users of computers, it's just that everyone hasn't learned to use them yet because programming is still too difficult.

CategoryAboutInteractionDesign CategoryComparisons