Producing Production Quality Software

A practical course on how to produce high-quality code

Fall 2005

Prof. Arthur P. Goldberg
Computer Science Department
New York University

Course Description

Update history: 8/10, 8/17, 8/22, 8/31, 9/3, 9/6


Consider these two cases:

In the late 1980s software problems in a computerized radiation therapy machine called the Therac-25 caused it to irradiate 6 patients with massive overdoses of radiation. Four patients died, while the others were seriously injured. Careful investigation points to an absence of concurrency control as the cause of the problem (Leveson and Turner, An Investigation of the Therac-25 Accidents).

After years of touting its Virtual Case File system as the pinnacle of case management software, in February 2005 the FBI informed a Senate Appropriations subcommittee that the project failed at a waste of $104 million. Thus, almost 4 years after 9/11 FBI agents still cannot use a modern computer system to manage information about terrorist and traditional cases (Wilson P. Dizard, Senators fume as FBI admits Trilogy foul-ups). The IT mismanagement problems that lead to this disaster are well documented and avoidable: US Department of Justice, Inspector General Audit Report, The Federal Bureau of Investigation's Management of the Trilogy Information Technology Modernization Project, and McGroddy and Lin, Editors, Committee on the FBI's Trilogy Information Technology Modernization Program, National Research Council, A Review of the FBI's Trilogy Information Technology Modernization Program (free pdf).

In this course you'll learn how to design and write software that won't accidentally kill people or waste millions of dollars and anger US senators.

Producing quality production software involves many crucial steps. These include requirements gathering, specification, effort estimation, design, implementation, testing and deployment. All software development models, from waterfall to iterative to agile, involve each of these steps to some degree. In this course you'll learn how to succeed in all of these steps, and acquire deep expertise and experience in design, implementation and testing.

This course will use Java. We will read a lot of code in class, and you'll implement your assignments in Java. The professor (and/or trained TAs) will read the code you write for assignments and propose improvements where applicable.

If you want to learn how to write great code, take this course.


The prerequisites for this course are skills, not particular classes. You should have the ability to program in Java. You should understand Java classes, methods, typing, collections, iterators, exception handling, and I/O. You should be capable of writing modest sized programs, 5 to 15 pages long, and have an appetite for reading and studying code.

Your responsibilities

Fundamentally, to acquire the skills I hope you'll learn, you need to enhance your talent for caring about software and the processes that create it. To be more specific, you'll need to practice these activities:

The specific assignments are to be determined.


I know this list is too big, but many people have written insightfully about software quality. Rather than follow a text, we will pick and choose highlights of these writings.


[SM] Steve C McConnell, Code Complete: A Practical Handbook of Software Construction, 2nd edition (June, 2004), Microsoft Press; ISBN: 0735619670.

Highly Recommended

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

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

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

Michael Feathers, Working Effectively with Legacy Code, Prentice Hall PTR (September 22, 2004), ISBN: 0131177052

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

Gerald M. Weinberg, Quality Software Management: First-Order Measurement, Dorset House Publishing Company, Incorporated (February 1, 1993), ISBN: 0932633242


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

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

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


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

David Gries, The Science of Programming, Springer Verlag; (January 1998), ISBN: 0387964800.

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.


Professor particulars

Email: artg at cs dot nyu dot edu

Office: 409 WWH
Office hours: 3 to 4 on Wednesdays and Thursdays
Phone: 212 998-3014

Course Information

Home page:
Number: G22.3033-006
Room: 102 WWH
Time: Wednesdays 5:00 PM - 6:50 PM
TA: TBD, if we have one

Rules for Working on Assignments

All assignments must be emailed to the professor and handed in on paper so the TA and/or professor can write comments and constructive feedback on it. To avoid problems with lost emails (e.g., “the Internet ate my homework”) please save a copy of your email to the professor (not simply the assignment itself).

Also, in recent years several students have lost significant work through system failures. Please backup all your files regularly. Work in progress should be saved every half quarter or so – remember to set the auto-save option – and all modified files should be copied to external storage daily.


Programming assignments


Classroom and mailing list participation


Oral final exam


Cheating Policy

The software you submit in assignments should be your own work.

The exception to this rule is that you may (should) use code that we explicitly provide or recommend as tools to help implement the assignment. For example, we may provide source code or indicate recommended libraries that you may incorporate in your work. If you want to use other libraries you should obtain the professor's permission to use them in a particular assignment. It is also OK to copy a one or two line comment that describes use of a function.

The distinction between improperly copying, which is cheating, and creating your own work is quite clear.

Cheating 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 after copying it.

The penalty for cheating depends on the severity of the offense. The following actions all increase the severity of cheating:

The professor may penalize cheating with a reduced grade for the assignment on which the cheating occurred, or a grade of F for the course. If the department believes a more severe penalty (i.e., probation, suspension, expulsion) is warranted, it can refer the case to the dean for further action.

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 g22_3033_006_fa05 <at>