Dan Bricklin's Web Site: www.bricklin.com
Why Johnny can't program
How the author constructs instructions to a computer, and how they can correctly anticipate the results, can affect acceptance of a system.
As a result of the Trellix blogging announcement I have been involved in a flurry of discussions with people about blogging, about various tools and features, and about differentiating the various blogging systems. One thing that came up in a discussion with Amy Wohl, as a follow up to her article about the Trellix offering, was this question: "How do you explain that function accessible through programming and function designed for consumers is not exactly the same thing?" Here are some of my thoughts (thank you Amy for inspiring me to address this!):

What is  "programming"?
What is it about traditional "programming" that keeps regular people from routinely doing it? And, when they do control a computer, why do some programming systems find wide usage among the "non-programmers" (like spreadsheets) and others don't (like C++)? I have some ideas why.

What is "programming"? A "program" could be defined as "a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result" (the "official" copyright law definition). "Programming" is creating those statements or instructions. The key to our question here, I believe, is how the author constructs those statements or instructions, and how they can correctly anticipate the results.

First, let's look at what makes up the "statements" or "instructions" in the program.

In a "traditional" program, the instructions are entered by the author into the computer in the form of "statements" such as lines of a Basic program or cell contents in a spreadsheet. The computer "executes" the statements in some logical order to bring about the result.
In less traditional "declarative" programming systems, the instructions are there, but the way the execution occurs is a little more mysterious, since the instruction are often more of constraints to be followed and relationships to use. A simplistic variant of this are systems where the constraints and relationships are specified using forms and pick-lists such as dialog boxes and menus.
Further from our traditional view of a "program", but now a very common way of bringing about a certain result in a computer, is to use a "WYSIWYG" environment, where there is what appears to be "direct manipulation" of the result. That manipulation is really changing instructions to bring about the result. It just looks like you are manipulating the result itself because the changes are made and the results recomputed so quickly. For example, dragging a column handle in a WYSIWYG HTML editor actually changes the "width=" attribute of the "<td>" tag. The HTML is a traditional programming language (remember the "L" in HTML is "language"). In WYSIWYG systems, there isn't always a human readable form for the instructions -- sometimes they are just stored in a computer-friendly form, with the results being enough for humans.

So, we have a variety of forms including: Typed statements following a particular syntax, constraints and other declarations (sometimes each chosen from lists), and direct manipulation of results.

There are some hybrid forms. A very common one is based on a menu and dialog-box driven "Fill-in-the-forms and drop downs" system but tied to a display of the results to give an almost WYSIWYG direct manipulation feel. These are declarative systems in that you usually just specify data, set relationships, etc., using the dialogs, and then the execution is done when you click "OK". They are tied to a graphical representation of the results so that when you click on appropriate places on the results the corresponding dialog box appears. They are "one click away direct manipulation": not quite direct, but almost. (Trellix's TWE web site authoring system is built this way.)

What makes one system easier or harder than another?
In Don Norman's wonderful book "The Psychology of Everyday Things" (now called "The Design of Everyday Things" in paperback) he provides these "principles of good design" (at the end of Chapter 2):

Visibility. By looking, the user can tell the state of the device and the alternatives for action.
A good conceptual model. The designer provides a good conceptual model for the user, with consistency in the presentation of operations and results and a coherent, consistent system image.
Good mappings. It is possible to determine the relationships between actions and results, between controls and their effects, and between the system state and what is visible.
Feedback. The user receives full and continuous feedback about the results of actions.

A traditional, "typed statement" programming environment (traditional "procedural" or "declarative") falls down on all of these. It is often very difficult to determine the relationships between operations and results. The feedback is not continuous -- because of syntax constraints there are many times that a program being modified is not in a state where you can see the results.

Menu and dialog-box driven "Fill-in-the-forms and drop downs" systems for controlling a computer are better. The alternatives are easier to choose, and when well designed the conceptual model is part of the presentation of the input. Usually seeing the result is only a click away, leading to a fast feedback loop.

Direct manipulation systems are best, and if well designed help on all of these areas.

Immersing yourself in details
Programming is a very error-prone business, especially with "typed-statement" systems. Most of them are very intolerant of errors (even simple typos). You must really have a good conceptual model of how each individual statement (and its sub-components) effects the result in conjunction with each other statement. You have to know how to check for proper operation (testing) and how to find out what to fix if it isn't (debugging). Unless you are totally immersed in that particular programming system (understanding the varieties and subtleties of its statements and functions) it is very hard for most people to do this. Most people will not get immersed in such systems that way.

My coworker Ed Blachman points out that this is not to say that many people can't get immersed in systems that require such understanding. They do in many parts of their lives. For example, lawyers and tax accountants routinely work with such complexity in their contracts and planning. Doctors work with an untold number of variables. Someone planning a big party has to work out the food, matching paper goods, favors, invitation list, entertainment, etc. Yet, all of these people rarely program computers in addition. It's just that people who aren't professional or hobbyist programmers usually don't want to get so immersed in something that is infrequently done and not part of the rest of their lives. The question really isn't "Why Johnny can't program" but rather "Why Johnny won't or doesn't choose to program".

"Fill-in-the-forms and drop downs" and direct manipulation systems require less learning, testing of results, and debugging. There are fewer chances for error because of the constrained input choices. Rapid viewing of the results makes it easier to make simple changes and see what happens.

Testing and debugging
The problems of debugging cannot be underestimated. Figuring out what is happening so you can "make it right" can be very frustrating. Programmers are a special type of person because they can tolerate this and have the patience to pore through manuals and stare at apparently incorrect lines of code to figure out how to fix problems. They have to author in a way to minimize the likelihood of errors. They need to figure out test cases to make the bugs show up earlier. This is not the way to get something done easily.

One of the problems with "typed-statement" systems is that even though each statement has an effect, you only see the final result. It is often unclear which statement (or interaction of statements) caused a particular problem. With a "Forms" or direct manipulation system, the granularity is often such that each input change has a corresponding result change.

In today's world, it is common for regular users encountering a "typed-statement" system (like HTML, Javascript, and Perl, for example) to just copy sample statements provided by others and incorporate them into their system. Sometimes this works perfectly, especially with error-tolerant systems like HTML. In most cases, though, this is very error-prone. A single typo, a slightly inappropriate placement of the copied code, an incorrectly set constant, or a lack of required libraries or other resources, can cause a result that just says "Error". Unless the author is well-versed in the system, doing debugging at this point, with the code consisting mainly of statements created by another, is very difficult and frustrating. It is common for the copier to be unaware of subtle errors in what they've done, since they don't know all of the test cases to try.

Intermediate results
David Reed commented to me that one of the good properties of a spreadsheet (leading to its wide acceptance) is that you usually set things up so that you can see the intermediate results of calculations. Rather than have one long formula in a cell, you use several cells, each with simpler formulas referring to some other cells. This makes testing and debugging much easier. Most traditional "typed-statement" systems make it very hard to show intermediate results, and require you to add "temporary" statements and output, or learn additional debugging systems. (That's why "Integrated Development Environments" have become so popular.) In addition to letting you see intermediate results, the recalculation ability of a spreadsheet, giving instant feedback, helped lead to Don Norman's conclusion that with a spreadsheet "...it felt as if you were working directly on the problem, not on a computer."

Conclusions
From all this you can see that the way a system requires an author to enter instructions into the computer affects the likelihood of acceptance by regular people. The more constrained the instructions the better. The more the instructions are clearly tied to various results the better. The more obvious and quickly the results may be examined the better.

Programming languages like Assembler, FORTRAN, C, and Java are least likely to be well accepted by the masses. Their syntaxes are very unforgiving.
Statement languages like HTML which are very forgiving of errors and with quick and obvious results are more likely to be accepted.
Integrated development environments, like Visual Basic and the old Turbo Pascal, with quick syntax checking, integrated debugging, and rapid movement to execution, are better than the old way for such languages.
Something like a spreadsheet, with very tight syntax checking, usually obvious connection between results and the statements that caused them, and easy display of intermediate results, are even better.
Use of dialog boxes for instructing a computer is generally more likely to be accepted than a "language". By additionally integrating a quick one-click-away display of the results with a connection back to the dialogs, this type of system has proven to be well accepted by regular non-programmers.
Direct manipulation, if the results being displayed are related well enough to the results for which you are programming, is even more likely to lead to acceptance.

- Dan Bricklin, 15 August 2002

A comment from Ed Blachman after seeing a final draft:

Your discussion focuses on complexity and difficulty, without looking at the other side of the coin: power/freedom. It's generally (though far from universally) true that each step toward programming difficulty is also a step in the direction of power and freedom... at any given time.

The two are not independent, as is illustrated by Trellix blogging. Formally speaking, Trellix blogging is an ease-of-use advance, because it does nothing that one could not have previously done manually in TWE. But the net effect to end users is a power advance: adding blogging to TWE doesn't affect TWE's overall ease-of-use, but does automate something that required a fairly complex set of manual activities.

- Ed Blachman, 15 August 2002

A comment from Amy Wohl:

While it is often thought that "real" programmers like real programming environments (my husband, for instance, is perfectly happy in MF Assembler, which is pretty grim), most programmers seem to become pretty happy moving up to graphical user interfaces and visual environments where they choose from a list of "correct" choices. I don't think it is only users that can be more productive when they are better supported.

I believe there is a direct relationship between the ease of use of a product or environment and the number of users it attracts. I also think that how deeply the users take advantage of the environment's capabilities is also a function of how they are offered. Users don't like to play hide and seek.

-Amy Wohl, 15 August 2002
© Copyright 1999-2018 by Daniel Bricklin
All Rights Reserved.