8.4 Other Findings about Programming in General

This section presents findings about programming in general that are not necessarily related to the use of CodeBroker, but are related to the theoretical framework discussed in Chapters 2 and 3.

8.4.1 Knowledge of Components and Problem Framing

In Chapter 2, I postulated that programming is an interaction between problem framing and problem solving, and knowledge about reusable components not only makes the solving process easier but also increases the programmers' capability of problem-framing because they can frame the problem directly with those components. Findings from the experiments support the claim.

Programming Task 3 (T3) (Section 8.2.3) was assigned to four subjects. Two subjects (S3 and S4) knew some classes in Java could be used, even though both of them had never used the classes and were not sure what the classes were and whether the classes included all the needed functionality. They described their understanding and implementation plan of the task as follows:

S3: ``There are two ways that I could do this. One way is that Java might actually have some supports in Java's international text classes for doing reading in Chinese format and then writing out in western format because I know there is a NumberFormat class, but I have never used it. And it might be easier for me to just do it by hand, which is to take the number, read it from right to left and then read it and write out another string, because it is pretty a simple thing. I have to take the comma from here and put it right here.''

S4: ``So what I want to do is that I will probably parse it using something like date format--I don't remember exactly what kind of number you can parse into--and then just reformat it into another way, another date format...oh, not date format, number format or something like that--java.util.text or java.text or something like that package. If it doesn't work, I am going to do it by hand: just remove the commas and insert them back. But I believe there should be a class that, given a pattern of a string, can convert it back to a string of another pattern.''

Two other subjects (S2 and S5), who did not know anything about those classes, described the same task as follows:

S2: ``I will convert the western number to an int primitive, run through the int-like StringBuffer backwards, throwing sets of four numbers into another StringBuffer. After each fourth number, check if there is a fifth number available; and if there is, insert a comma. At the end, simply reversing the string should give you the Chinese number.''^8.5

S5: ``Basically, I am gonna to parse the number, take out the commas and insert the commas.''

Apparently, the problem descriptions of S3 and S4 were strongly affected by their knowledge about components, whereas S2 and S5 described a more detailed, lower-level implementation plan. As a result, both S3 and S4 implemented the task in a very compact way using components delivered by CodeBroker. S2 implemented the task as he described because the system failed to deliver relevant components based on his comments. S5 came up with a compact implementation too because the CodeBroker system delivered components from the NumberFormat class.

8.4.2 The Opportunistic Nature of Programming

The example of S5 implementing T3 well illustrates the opportunistic nature of programming (Section 2.3). According to his original implementation plan, S5 first started with creating two method interfaces: one reads the inputted number, and another one converts and returns it. However, based on the doc comment he wrote for the second method, the CodeBroker delivered the format method of the java.text.NumberFormat class. S5 noticed it, browsed its document, and totally changed his original implementation plan. His final implementation was very close to the one created by S3, who anticipated the existence of the format method.

This example showed that actively delivered components augment programmers' insufficient programming knowledge and create learning and reuse opportunities for programmers. The phenomenon that delivered components changed a programmer's original implementation plan was also observed in experiments with two other subjects.

8.4.3 Four Levels of Knowledge about Components

Not surprisingly, the subjects did have four different levels (Figure 4.1) of knowledge about components in the repository. The disparity between L3 and L4 was very obvious in all subjects. For example, neither S2 nor S5 knew the existence of the format method. Some subjects knew a lot about GUI packages, whereas others knew a lot about the java.lang package. Subjects who had had more Java programming experience had more anticipation of the repository because they had explored the repository more often than less experienced ones. Some of the anticipations were transferred from their programming experience with other programming languages. Sometimes, subjects anticipated the existence of components that were not included in the repository.^8.6 For example, one subject thought there should be a method of filling a sequence with a sequence of numbers. Before he gave up and wrote his own code, he first wrote a comment in his program, hoping the system could deliver it, and then browsed the documentation system quite thoroughly, trying to find the nonexistent component. Even after he had finished his program, he still believed the component should exist in the repository, and he said: ``I am not sure there is not a fill method [that can fill a sequence with a sequence of numbers].''

For those components that subjects had used before, there was a difference of levels of mastery (L1 and L2) as well. As expected, many components were reused by subjects directly, without consulting documents. However, in one experiment (S2-T5), the subject (S2) relied on the delivery mechanism to reuse one component he claimed he had used many times before but could not remember its exact name, even though he knew that it was a static method.

8.4.4 Learning Task-Relevant Components on Demand

One important factor that contributes to the importance of the learning-on-demand model (Section 3.4.3) is that learning is more effective within the working context because programmers are more motivated to learn new things that can be immediately applied to their task at hand, and the existence of application working context makes learning easier. Observation of the experiments confirmed this claim, and the following example is quite typical in all experiments.

In the previously cited example (Section 8.4.1), both S3 and S4 had not known how to use the class of java.text.NumberFormat and what kind of functionality it had,^8.7, and S5 had not even known the existence of the java.text package. When the format method from that class was delivered, all of them realized they could use it. However, in order to use the format method, they needed to know how the class was structured and also needed other methods from the same class to implement the task. Despite their claims in the beginning that they could easily implement the task with their known knowledge, they were all very motivated to learn how to use the format method and other related methods. It took S3 and S4 more than 15 minutes, and S5 more than 30 minutes to learn all the needed methods. Given the fact that they all are expert programmers with extensive programming knowledge, learning those components probably cost them more time than had they just implemented the task by hand. However, they all were determined to learn those new components because they wanted to use those components instead of creating their own primitive solutions.