A practical course on how to produce high-quality code
Arthur P. Goldberg
Computer Science Department
New York University
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.
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:
Patiently design systems and code. You'll design a system using multiple approaches, to compare the effectiveness of each approach. Then I'd like you to try the same experiment with another system, and compare the results. Perhaps different approaches work better for different systems.
Carefully read code and comment on its strengths and weaknesses; you'll read both other people's code (which is easy) and your own (which some people find very difficult). You'll need to read code both in class and for assignments.
Thoroughly test software. Again, you will be responsible for testing both other people's code and your own. And again, many of you may find this easier to do on other people's code.
Finally, we cannot write great code unless we can talk about software, and discuss its merits and problems, and the processes that create it. As the semester progresses I'll create a list of questions in this vein. The list will become the basis for a final oral exam.
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.
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.
Email: artg at cs dot nyu dot edu
Office: 409 WWH
Office hours: 3 to 4 on Wednesdays and Thursdays
Phone: 212 998-3014
Room: 102 WWH
Time: Wednesdays 5:00 PM - 6:50 PM
TA: TBD, if we have one
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.
Classroom and mailing list participation
Oral final exam
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:
Copying more code
Modifying the code to conceal that it is a copy (i.e., changing the name of the author, or modifying the code by changing variable names, indentation, linebreaks, etc.)
Lying about whether you cheated
Taking more NYU faculty or staff time to deal with the 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.
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
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> cs.nyu.edu.