A Freshman Programming Course: Two Challenging Sets of Students, One Solution

Jeanne L. Murtagh Department of Electrical Engineering and Computer Science United States Military Academy West Point, NY 10996 Abstract
This paper identifies two categories of students who pose a significant teaching challenge in a college freshman programming class, and then discusses one effective way to improve their performance. The most challenging students are those who do not readily adopt a systematic approach to software development. These students tend to fall into two categories: a) The High School Hackers b) The Haphazard Never- vers E High School Hackers do not use (and might not acknowledge the value of) a systematic approach to software development. Haphazard Never-Evers have trouble adhering to the systematic approach they are trying to learn. Providing these students with a one-page summary which includes the steps of a structured software development methodology -- enhanced by detailed instructions for writing the source code -- is a very effective way to help them learn and adhere to the systematic approach so critical to their success. High School Hackers often have extensive unstructured programming experience. Note that this term is not being applied to all students with programming experience in high school. It is being used specifically to designate people with programming experience, but without exposure to a systematic approach to software development. High School Hackers will normally read a problem statement and immediately start typing code, rather than wasting time on planning and design. This approach can be effective for simple problems. In fact, if the problem is simple enough that the hacker can implicitly, rather than explicitly, provide the structure needed to solve the problem, then this approach saves overhead and allows the hacker to produce an acceptable solution in a minimum amount of time. The problem with this approach, of course, is its lack of extensibility [1]. It cannot be scaled up and used effectively on problems of a more interesting (i.e., more realistic) size [2]. The first challenge is to help the High School Hacker recognize this problem of scale, and the need for a more structured approach. This is frequently resolved by the size and complexity of the assignments encountered in the college programming class. The second challenge is to present the systematic approach in a way which clearly demonstrates its advantages and ease of use. Haphazard Never- vers E The students enrolled in an introductory computer class are likely to have widely varied backgrounds. It might be easy to teach those who already have extensive experience developing software using a logical, systematic approach. It might also be easy to teach enthusiastic neverevers (people without previous programming experience) who quickly grasp software development concepts. However, you are likely to encounter two other categories of students as well: a) The High School Hackers b) The Haphazard NeverEvers High School Hackers Haphazard Never-Evers have trouble adhering to the systematic approach they are trying to learn. Unlike the High School Hackers, who are often quite proficient at producing small programs, the Haphazard Never-Evers cannot implicitly structure their programs. They need easy access to explicit step by step instructions.

The Challenge

The Solution
Which Systematic Approach? In order to succeed in a freshman programming class and to lay the foundation for success in upper-level computer science classes, students will need to learn and then employ a systematic approach to software development. Our broad description of this process is taken from DiElsis Software Design Methodology [3], which is based on top-down design. This is quite effective, since the goal of our course is to explore problem solving and critical thinking, and then to apply these skills to the domain of software development. We focus on stepwise refinement of the solution, which results in main programs consisting primarily of procedure calls [4]. This approach also allows a computer program to be grown by incremental development [5]. This means that complexity is added to the software hierarchically, as advocated by Brooks [6]. The approach is not inherently limited to the toy programs developed in a freshman programming class; the exact same approach can be scaled up and applied to commercially significant programs. Therefore, it provides an excellent foundation for future study in computer science. Why Do We Need The One-Page Reference Card? We found that many of our students benefited from the easy access to specific instructions on the one-page reference card, How to Write A Program: A Step by Step Approach, which is included as Attachment 1. This was especially true for the High School Hackers and the Haphazard Never-Evers enrolled in the class. The most critical part of the reference card, the expansion of Step 4 (production of the code), was prepared by us to help students apply the same logical, top-down approach to writing the source code that they had applied to the rest of the software development process. Although textbooks often address code development at a rather high level, few textbooks address it this specifically. This enumeration of the top-down steps for writing source code has several advantages. It

simplifies the error-hunting process. Syntactic errors can now be attributed to only the last procedure entered, regardless of the number and location of the errors reported by the compiler. Toplevel program flow can be observed when only the main program and stubs for its procedures have been completed. The demoralizing effect of 80 compiletime errors in 200 lines of source code is avoided. A student who runs out of time to complete the entire project is likely to have a reasonable executable program, containing a subset of the required functionality, to submit for grading.

Conclusion
Both the High School Hackers and the Haphazard Never-Evers experienced greater success in our freshman programming class when they used the one-page reference, How to Write A Program: A Step by Step Approach.

References
1. Weinberg, Gerald M., The Psychology of Computer Programming, Van Nostrand Reinhold, 1971, p. 190. 2. Brooks, Frederick P., Jr, The Mythical ManMonth, Anniversary Edition, Addison-Wesley, 1995, p. 183. 3. DiElsi, John, Turbo Pascal 6.0: The Nuts and Bolts of Program Construction, McGraw-Hill, 1991, pp. 23 - 29. 4. Smith, James and Frank, Thomas, Introduction to Programming Concepts and Methods with Ada, McGraw-Hill, 1994, pp. 249 -250, 258 - 260. 5. Brooks, p. 201. 6. Brooks, p. 212.

Jeanne L. Murtagh
Maj Jeanne L. Murtagh is an active duty Air Force officer, specializing in acquisition of real-time software for weapon systems. She is a 1982 graduate of Rensselaer Polytechnic Institute (BSCS) and 1985 graduate of Boston University (MSCS). She is currently assigned to the Electrical Engineering and Computer Science Faculty at the United States Military Academy, West Point, NY. She has previously served in Air Force Systems Command and Air Education and Training Command. Her research interests include software engineering and curriculum development. She can be reached at [email protected].

Attachment 1: The One-Page Reference Card:

The next two pages contain the software development summary reference card used in the version of our Ada freshman programming class. [Note: Step 4.0, at the top of the next page, contains some instructions which were specific to our Ada Integrated Development Environment.] These two pages were each printed on 8.5 x 11 inch paper, using a 12point Times New Roman font, resulting in a 17 x 11 inch master. This was reproduced as one 8.5 x 11 inch reference card, using the appropriate reduce-and-copy settings, printed on card stock (for durability), and provided to all students. They were strongly encouraged to use the card whenever they developed software for the class. [Note: This card also refers to an Ada Syntax Summary Reference Card, which summarized the syntax of all constructs used in our freshman Ada programming course. This allowed us to focus on problem solving and application of the concepts involved in software development, rather than memorization of syntactic details.] How to Write a Program: A Step by Step Approach Step 1: Analyze the problem. What do you have to do? Identify your INPUTs and OUTPUTs. (Note: You will need VARIABLES for these.) Example: 1 = name_of_item: Name_type (string of length defined by a constant; see syntax reference card) 2 = original_price: real (or perhaps ofprice_type -- which is derived from real) 3 = new_price : same data type asoriginal_price Step 2: Draw the STRUCTURE CHART. It will almost always have least four boxes. Continue to divide the problem at (adding boxes to represent additional procedures) until you are confident that you can manage the complexity of each procedure. OVERALL PROBLEM: Pricing_Report_for_New_Equipment

1 2

INPUT: Get_Data Notes:

PROCESSING: Compute_New_Price

OUTPUT: Report_Results

1) It is a good idea to LABEL each box as shown above (Overall Problem, Input, Processing, Output). This clearly demonstrates that you understand the primary pieces of the problem. Of course, in addition to these generic labels, you must also select titles -- which arespecific to the problem you are trying to solve for each box. -2) Each box in your structure chart will usually be implemented by one procedure in your program. 3) Show the parameters and their parameter passing mode (in, out or in out) for each procedure. Step 3: Write the PSEUDOCODE for each procedure. Try to make it detailed enough to provide a thorough description of the algorithm you will use. This will make it much easier for you to complete the next step.

How to Write a Program: A Step by Step Approach (cont) Step 4: Write the code. FOLLOW A LOGICAL STEP BY STEP APPROACH !!! Step 4.0: Open a new window in theAda Integrated Development Environment. IMMEDIATELY save it under an appropriate name (ex: A:\MyProg.Ada). Step 4.1: Write the MAIN program SHELL (see PROCEDURE FORMAT -- MAIN Program on your Syntax Ada Summary Reference Card). This shell should include the following: 1) HEADER: Complete 2) PROCESSING Section: STUB: BEGIN text_io.put_line( Stub for procedure <name of procedure>...); END <name of procedure> ; SAVE your program shell, and then COMPILE it. Step 4.2: Declare your main program CONSTANTS, TYPES, and VARIABLES (as a minimum, youll need variables for your inputs and outputs). SAVE your program, and then COMPILE it. Step 4.3: Write the PROCESSING SECTION of the MAIN program. This will consist primarily of calls to the procedures you identified when you built your structure chart. Step 4.4: Write the STUBS for the procedures called by your main program. Use your Syntax Summary Reference Ada Card. Procedure stubs must contain the following: 1) Internal Procedure HEADER: Must be complete (i.e., including parameter list!) 2) Internal Procedure PROCESSING Section: STUB (see description of procedure stub -- step 4.1 above) SAVE your program, and then COMPILE it. Step 4.5: Now its time to write the PROCESSING SECTION of each procedure. HINTS: 1) Write ONE at a time, and SAVE and COMPILE after you finish each procedure. Note 1: This simplifies error-hunting ! Note 2: Write additional procedure stubs when you need them to keep your program compiling! (i.e., write the new stub when the procedure you are currently writing calls that new procedure.) 2) If you get stuck on a procedure, try these approaches: Plan A: Provide the absolute minimum functionality which this procedure must contain in order to allow the rest of the program to run. Examples: i) Provide simple user prompts and statements to get the inputs first, then add the error checking. ii) If you cannot make a computation compile, simply use an assignment statement and set the value to a reasonable default, so you can still test the rest of your program. Plan B: Comment out each line of the code in the processing section of that procedure (so the rest of your program will still compile) and move on to a different procedure. Come back and finish the hard procedure if you have time left! Step 5: Test the program. Step 6: Complete your documentation. Consider using comments to explain a particularly clever (or confusing!) section of code!