Programming: A Series of Interesting Decisions

Imagine you are watching a Java programmer writing some code. Can you predict what they are most likely to do next in each of these situations?

  • The programmer moves the cursor to a new line, and types the three characters “boo”. What will they type next?
  • The programmer types “x = gteLength();” then gets an error that the method name is unknown. There is a method declared in the class named “getLength()”. What will the programmer do now?
  • The programmer types “ArrayList items;”. No class named ArrayList has been imported, but the standard library class java.util.ArrayList exists. What will the programmer do now?
  • The programmer has a variable named “old”. They have just renamed the declaration to “oldValue”. Now all the uses of the variable “old” are showing an error that the variable “old” does not exist. What will the programmer do next?

No prizes for guessing the most likely action in each case (but to be clear: type “lean” to make “boolean”, correct the typo, import the ArrayList class, change all the uses of “old” to use “oldValue”). These are so obvious that most IDEs now have automated support for helping in these situations. In Eclipse, Ctrl-Space (then Enter) will complete “boo” into “boolean”, hovering over the second error will offer a one-click option to correct the method name, pressing Ctrl-Shift-O in the third case will import the java.util.ArrayList class for you, and pressing Alt-Shift-R before renaming in the fourth case will rename all uses of the variable at the same time.


One measure of a computer interface, such as an IDE, is the extent to which it reduces the predictability of your next sequence of actions. This may initially sound odd, but your next actions should always be hard to predict — if it’s easy to predict the next sequence of actions (e.g. “boo” being followed by “lean”), the interface should roll it into one action (code completion) or, if it’s 99+% clear what the action will be, just do it for you. Contrast the boo-lean case with what the programmer is going to type when they’ve just written “int ” in a method — it will be a new variable name, but it’s very difficult to predict what the name will be.

There are parallels to information entropy here — the letter E was one dot in morse code because it makes sense that the most frequent action has the shortest code. Similarly here, the most likely behaviour should have the shortest sequence of interface actions to trigger it. (You have to be a bit careful because the user might not want to fix the error immediately, especially in the third case. They may want to keep coding, so you don’t want to interrupt them with a dialog or anything too extreme.)

IDEs in Education

In a professional IDE, the goal is to support an expert programmer in writing good code quickly. However, our team makes educational IDEs, which have a different goal: to support novice programmers in learning how to program. Assistance can of course be positive — it can help move novices past the boring, frustrating parts of learning coding (syntax errors, obscure error messages) on to the interesting parts (like algorithms and design). However, assistance can also have downsides for novices:

  • If you present novices with a list of actions, they may not understand them fully, and may choose one just because it’s available. For example, “You are trying to pass a Person to this method but the type required is the Product interface. Do you want to (a) cast Person to Product or (b) let Person implement the Product interface?” The correct fix is to pass a different value as that argument, but that fix is not offered — a novice may think the only possible fixes are those in the list.
  • Doing too much in one action may lead to not understanding what assistance was given. For example, Eclipse has an option to pick a parent method from a class and override it. Will students understand why the “public void setLocation(int x, int y)” method in Crab overrides a corresponding method in Actor (but “public void setLocation(double x, double y)” does not)? At the extreme case, you don’t want Clippy popping up with “You seem to have written a bug in your quicksort implementation. Click here to automatically fix it”.
  • Too much assistance may be overwhelming at first. Some IDEs start offering completion as soon as you start typing a type or method name. If all the novice is trying to do is write their first variable declarion, do you want to present them, unbidden, with a popup list with all the available classes in the Java standard library?

There is no single right or wrong answer to these issues, and the question of how much assistance is the right level to provide. In the past, BlueJ and Greenfoot have offered only minimal assistance, preferring too little rather than too much. However, in our work at the moment on Greenfoot 3, we are moving towards having more assistance: code completion will be more featured (though I think it will still not popup automatically), and there will generally be more help offered by the environment in writing code and correcting errors.

Postscript: The title for this post comes from Sid Meier, who said that games (which, for him, means strategy games) are “A series of interesting decisions”. If there are no decisions to be made then there is no player involvement and there is not much point in them being sat there. If the decisions are obvious, then you are wasting the player’s time. The reason for the player to be involved is that there is a non-obvious decision for them to make. This seems to me to have a clear parallel in designing interfaces.

3 thoughts on “Programming: A Series of Interesting Decisions

  1. What about the idea of making all the “assistance” customizable? I’m actually thinking in terms of “reverse scaffolding.” In other words, in the beginning there’s virtually no assistance (as it is now in Greenfoot). But then as the student progresses more assistance becomes available (auto completion of method names, etc.). But always the user has the ability to turn specific features on or off.

    1. I like the idea. Ideally I’d want to dial up the assistance automatically, but trying to programatically decide when a user is ready for more assistance is probably a research project in itself. So we could just have some options that turn it on and off, with off as the default. However, we have generally tried to keep configuration options at a minimum in Greenfoot so that there is less configuration to have to mess around with, and everyone gets the same experience. So we have to balance our desire for minimum configuration against configurable assistance — we will think about it.

  2. I knew a PhD student who implemented adaptable scaffolding in his programming environment (for high school students building physics simulations). For his top students, it worked great — they worked with scaffolding on for awhile, then turned off scaffolding as they developed expertise, then turned scaffolding *back on* when they were working on something particularly hard. However, for the least-able students, it was a disaster. As soon as they were shown how to turn off scaffolding, they turned everything off, never turned it back on, and totally floundered.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s