Producing Production Quality Software


101 WWH
Wed 5:00 PM - 6:50 PM
Prof. Arthur P. Goldberg
This page is at

TA: David Westbrook.
Office hours: Mondays, 1-3
Office: Room 708, 719 Broadway, 8-3518


How to produce high-quality code, a practical course.


Obtaining good requirements and writing accurate specifications.
Inspecting requirements, specifications and code.
Using pseudocode to describe algorithms.

Small to medium sized programs:
Accurately implementing the specifications. Writing simple code:
function and class decomposition;
O-O class hierarchies (deciding whether to use composition or inheritance). Using libraries (data structure selection).
Practical code correctness: using invariants.
Unit testing. Using assertions(). JUnit (or something better). Writing tests in advance (Extreme programming).
Coverage testing.

Large programs:
Module decomposition and interfaces.
File & class organization.

We will look at a lot of code in class.


The ability to program in Java, including understanding of classes, methods, Java typing, collections, iterators, exception handling, and I/O. If you do not like programming, do not take this class.

General Information

If you do not like programming, do not take this class.  If you want to learn how to write GREAT code, take this course.  We will look at a lot of code in class.  
Prerequisite: the ability to program in Java, including understanding of control flow, classes, methods, exception handling, java.util collections, iterators, and file and stream I/O.  The professor (or trained TAs) will read and review all student code.


Text in '[]' brackets is tentative.
Classroom Activities
Introduction, course overview
Lecture 0: Introduction
Review Lecture 0: Introduction and this Syllabus;binary search code: specify and review,
binary search code: specify and review answer
Practice recognizing problems with other people’s code and Quality Code guidelines; their rationale
Software Quality Guidelines,
Lecture 1: Examples of Bad Code
GG: Chapter 3: Overview of Software Inspections
Review Software Quality Guidelines and Lecture 1; students do Example X from Lecture 1;
Review  Binary Search: Invariants—Repeated Assertions
Pseudocode/PDL approach to design and implementation
An Example of Good Code-My SMTP Answer;
Lecture 2: An Approach to Writing Better Code
SM: Sections 3.3 and 3.4, and Chapter 4
Review Lecture 2, and students start following the approach
OO  Design
Lecture 3: Design Do an OO design problem, ViaNet Bank
testing phases:
QA; independent testing;
‘Glass box’ testing; coverage testing: choosing good test inputs; structured basis testing
Writing tests in advance;
digression--extreme programming summary;
How to use Junit
Lecture 4: Testing; Lecture 4b: Testing Limitations
junit.framework Class Assert
SM: Chapter 25, Unit Testing
JUnitTest Infected: Programmers Love Writing Tests

Demo some How To Break Software examples
Error Handling;
error types;
Lecture 5 Error Handling
Lecture 5b Error Handling with Java Exceptions
P: Chapter 6, Handling Exceptions

[Figure which code is error handling code in some production code]
System Design in Java;
File & class organization;
OO hierarchy;
Deciding whether to use OO composition or inheritance;
Lecture 6: System Design In Java
Lecture 6b: System Design In Java, Example Code
P: Chapter 22, Inherit It

[OO design for the ‘include’ problem in 'Software Tools in Pascal'; or ‘design a simple file merge sort'];
Other design methodologies:
data flow diagrams;
structured design; top-down design; bottom up design
Lecture 7: More Design Methodologies

P: Chapter 11, Who’s the Boss
Lecture7 Exercises, make data flow diagram, design a simple file merge sort, etc.

Other design methodologies continued:
Processing semi-structured input with REs, FSMs, and CFGs
[Small languages; JavaCC]
Lecture 8: Processing Semi-Structured Input
Lecture 8: Processing Semi-Structured Input, Handout
P: Chapter 3, Generating Data
P: Chapter 4, Finite State Machines

Discuss P: Chapter 3
Review java FSM builder; TCP example
Design Patterns
Gamma et. al., Handout, Chapters 1,  most of 2, and Abstract Factory
Erich Gamma, Kent Beck, JUnit A Cook's Tour
Review JUnit A Cook's Tour
Module decomposition and interfaces
SM: Chapter 3.4
Design DBMS architecture
Black box, or functional, testing;
its limitations;
Lecture 11: Black Box Testing
Lecture 11: Blackbox Testing Handout

Review examples of bad code that survived functional testing of IMAP web servers;
More demonstrations with How To Break Software; use CannedHEAT
Group programming issues:
Group dynamics, team work
SM: Chapter 20, 21, 22
[Some Weinberg writing TBD]


[some of Van Roy and Seif Haridi]
Java on threads and synchronization
[Show my lock code; Show concurrentupdate exception]



[SM] Steve C McConnell, Code Complete: A Practical Handbook of Software Construction, 857 pages (May 1993), Microsoft Press; ISBN: 1556154844.

[P] Plauger, P. J., Programming on Purpose, Prentice Hall, 1993, or Pearson Education POD; 1st edition (November 5, 1997), ISBN: 0137213743.

Recommended and Perhaps Excerpted

[GG] Tom Gilb, Dorothy Graham, Software Inspection, Publisher: Addison-Wesley Pub Co; ISBN: 0201631814; 1st edition (December 1993).

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Grady Booch (Designer), Design Patterns: Elements of Reusable Object-Oriented Software, (October 1995), Addison-Wesley Pub Co; ISBN: 0201633612

Karl E. Wiegers,  Peer Reviews in Software: A Practical Guide, Publisher: Addison Wesley Professional; ISBN: 0201734850; 1st edition (December 15, 2001)

Capers Jones, Software Assessments, Benchmarks, and Best Practices, Addison-Wesley Pub Co; 1st edition (April 28, 2000), ISBN: 0201485427

David Gries, The Science of Programming, Springer Verlag; (January 1998),  ISBN: 0387964800.
Bill Hetzel, The Complete Guide to Software Testing, September 1993 (or a better testing book)

Brian W. Kernighan, P. J. Plauger, The Elements of Programming Style, Computing McGraw-Hill; 2nd edition (June 1979) out of print

Brian W. Kernighan, P. J. Plauger (Contributor), Software Tools in Pascal, Addison-Wesley Pub Co; (January 1, 1981), ISBN: 0201103427.

Jon Louis Bentley, Programming Pearls (2nd Edition), Addison-Wesley Pub Co; 2nd edition (September 27, 1999), ISBN: 0201657880

Jon Louis Bentley, More Programming Pearls: Confessions of a Coder, Pearson Education POD; Facsimile edition (February 1988), ASIN: 0201118890

John Lakos, Large-Scale C++ Software Design, Addison-Wesley Pub Co; 1st edition (July 1996), ISBN: 0201633620


Due Week Relative Importance
Implement a binary search; answer
Code Inspection of Example Y; answer
Complete development of "is a column in one table a possible foreign key", following the "Top-down Design, Pseudocode Approach"; write it up like I did in Lecture 2.   Include your unit test code and testing output.  Try to follow the Software Quality Guidelines. You may reuse my code from Lecture 2.  Ignore what I said in class last night and implement a tokenizer that will properly return nulls when parsing csv lines. As I did, only implement requirements 1 and 2 of the csv 'spec':
Fields are separated by commas.
Leading and trailing space-characters adjacent to comma field separators are ignored.

Complete the design of the ViaNet bank ATM; answer



Testing;assignment update

Different Design Methodologies; Sample answer


15 (on 12/14)
A Universal Relation Processor; 12-01 version with changes tracked; clean 12-01 version; 12-08 version with changes tracked, Assignment Submission Web site

Rules for Working on Assignments

All assignments must be emailed to the professor and handed in on paper so I can write comments and constructive feedback on it.  To avoid problems with "lost emails" ("the Internet ate my homework") you should save a copy of your email (not simply the assignment itself).

Late Assignments

Assignments are assessed a 1.5% penalty per day late.  Since I want to hand out and discuss answers 1 weeks after the due date, NO credit will be given for ANY assignment submitted later than one week after the due date.

Cheating Policy

The software you submit in assignments should be your own work.  The only exception is that you may (should) use code that we provide that you for use in your work.
The distinction between improper copying, which is cheating, and your own work is quite clear.
Improper copying occurs when you incorporate into your own code multiple lines of code that someone else wrote.  The copying is improper even if you modify the code.
Modifying the code to conceal that it is a copy (i.e., changing variable names, indentation, linebreaks, etc.) makes the cheating worse.
We expect and hope that you will read other code and documentation to help you write your software.  It is OK to copy a brief comment that describes use of a function.  It is OK, and encouraged, to use libraries that implement useful functionality.  However, check which libraries are permitted by a particular assignment.

The penalty for first cheating offense will be a grade of ZERO on the assignment on which the cheating occurred.. The penalty for a second cheating offense will be a grade of F for the course.


Programming assignments
Classroom participation

Class Email List

All students must register with the class email list, which is used for all technical and logistical discussions concerning the course. To register, go to the following web page, and follow the instructions:

Please send your questions to this list so that everyone may participate in the discussion.   To post a message to all the list members, send email to ody> >