Fig. 1: If your IDE looks like this,
you're doing it wrong.

Evolution 4 (Hilton)

-	-	-	-
Days	Hrs	Mins	Secs

Evolution 4 (Bletsch)

-	-	-	-
Days	Hrs	Mins	Secs

Overview

Links

• Forum (Piazza)
• Syllabus
• Project requirements: (REDACTED)

Schedule

• Thu 1/14 Introduction
  • Bletsch slides
  • Hilton slides
• Tue 1/19 Programming Languages: Which one to use?
  READING: Beating the Averages by Paul Graham (the Blub Paradox)
  Your group's first design decision will be which language to implement your project in. Accordingly, our first class discussion will focus on topics to consider in making your language selection. Here are some concrete discussion points to consider:
  • What language features make a programming language "Good"?
  • Why are these features important?
  • How do the relative importance of those features change in different situations?
  • Consider a handful of programming languages which you know—how well (or poorly) do these languages provide the features you described above?
  • Briefly research some other language you are not as familiar with—how well (or poorly) does this language provide the features you described above? (Ideas for languages to consider: Scala, SML (or OCaml), Smalltalk (or Squeak), Scheme).
  When you submit stage 1 of your project, include a small section describing your rational for the language choice you made. When writing up later stages, evaluate how this choice set you up to win or struggle in modifying your code.
• Thu 1/21 Good Design: What is it?
  READING: Basics of the Unix Philosophy from The Art of Unix Programming by Eric S. Raymond
  The primary goal of this course is to get you thinking about how to design software better. Accordingly, our second class discussion will focus on what we consider to be "Good" design. Here are some concrete discussion points to consider:
  • What are the hallmarks of a Good design?
  • What are the hallmarks of a Bad design?
  • How do these considerations tie into the language features you found desirable?
  • How do you plan to ensure good design?
  • How can you evaluate the Goodness of your design...
    • ...in the planning stages?
    • ...in the implementation stages?
    • ...when maintaining it?
  • If you made bad design decisions, how do you decide between sticking with it and redoing it?
  The design considerations from this discussion should guide your writeup of the submission of all stages.
• Tue 1/26 Workday
• Thu 1/28 Scale of Design: Programming in the Large vs Programming in the Small
  READING: Sections 5.1 and 5.2 of Chapter 5 of Code Complete by Steve McConnell
  When we design programs, we actually have two very different tasks: Programming in the Large (PitL) and Programming in the Small (PitS). In the former, we consider large scale design considerations: modules, their interfaces, ... In the later, we consider design considerations on a much smaller scale: implementation of a module, class, or function.
  • Which of your good design/bad design features contribute to PitL, and which to PitS?
  • Which of the important language features that you identified earlier are important for PitL vs PitS?
  • How do the two tasks relate? Are they mutually exclusive? Serially dependent? Iterative refinements of each other?
  • Which is more important: PitL or PitS? Put a different way, if you had to work on a piece of software which did one excellently and one badly, would you prefer good PitL design coupled with poor PitS design or poor PitL and good PitS?
  • Which scale of design aspects is easier to modify when requirements change? How does the answer to this question inform our design decisions?
• Tue 2/2 Workday
• Thu 2/4 Writing: how do we do it well? How does it relate to programming?
  READING: The Bill of “Writes” by Beryl Pittman
  Your first stage is due soon, which means you are hopefully starting to write it up. In this discussion, we are going to talk about what makes good writing versus bad writing, and look for parallels with program design. Specific discussion points to consider include:
  • What are the hallmarks of a well written document?
  • How can you tell if what you have written is good or bad? If you identify something as being poorly written, how do you improve on it?
  • Compare and contrast good writing and good program design.
  • Compare and contrast the process of writing with the process of programming.
  For all of these, contemplate ties to the previous discussions.
• Tue 2/9 Evolution 1 Oral Presentations.
  (Recommended reading for presenters: The Listener's Bill of Rights by Beryl Pittman)
• Thu 2/11 Workday
• Tue 2/16 Workday
• Thu 2/18 Teamwork: impact of teamwork on programming
  Today's discussion will focus on programming as a team effort:
  • What benefits does team programming have?
  • What difficulties does it introduce?
  • What tools/techniques are popular to enhance team programming?
  • Which of these does your team use? Why (or why not)?
  • How does team size affect the benefits/difficulties of team programming efforts?
• Tue 2/23 Workday
• Thu 2/25 Documentation:
  Most programmer's hate writing documentation, but wish they had more of it to read...
  • How much documentation has your team written? What form does this take?
  • How happy have you been with the level of documentation in your code?
  • What makes good documentation?
  • Why do programmers often neglect documentation?
  • How do you overcome this and get your team to document code properly?
• Tue 3/1 Evolution 2 Oral Presentations.
• Thu 3/3 Workday
• Tue 3/8 Testing
  READING: Software Testing by Sarah Heckman — a primer on the fundamentals
  Testing is an important part of the software creation process. In a healthy development environment, testing is generally automated and regular, including nightly regression testing and a robust, end-to-end QA effort conducted before release. Today, we talk about how it fits into the design process.
  • Where do tests come from? How does testing differ from debugging?
  • How do you automate testing? When should automatic testing occur?
  • How can your design decisions simplify (or complicate) testing?
  • How do you design for testability?
  • How does your testing infrastructure/plan have to change in the face of changing requirements?
  • Can you design your testing infrastructure/plans to be more resilient to evolution?
• Thu 3/10 Workday
• Tue 3/15 Spring Break (No class)
• Thu 3/17 Spring Break (No class)
• Tue 3/22 Workday
• Thu 3/24 Debugging: can your design make it easier?
  READING: The case of the disabled logins — an interesting diagnosis of a malfunctioning Linux-based kiosk
  Most programmers spend more time debugging code than writing it. How can our design improve our debugging process?
  • When in the programming process is our code must vulnerable to introduction of bugs?
  • How can our design decisions reduce (or increase) the prevalence of bugs?
  • How can our design decisions simplify (or complicate) debugging?
  • What constitutes "good" debugging practices?
• Tue 3/29 Evolution 3 Oral Presentations.
  
• Thu 3/31 Workday
• Tue 4/5 Maintainability and Refactoring vs. Rewriting:
  READING: Things You Should Never Do, Part I by Joel Spolsky
  READING: How To Survive a Ground-Up Rewrite Without Losing Your Sanity by Dan Milstein
  You are almost done with the semester, and have just about finished three evolutions of the requirements. Hopefully you have significant thoughts on maintaining code in the face of changing requirements, the topic of today's discussion:
  • What kind of evolutions were most difficult to deal with?
  • Can you generalize what makes a specific type of requirement evolution easy or hard to deal with?
  • What makes code easy (or hard) to maintain?
  • How does this inform our design decisions?
  • What is different when you modify code someone else wrote? How do you mitigate these difficulties?
  • Did you ever consider a rewrite of all/part of your project? What are the pros/cons of a rewrite vs. a refactor?
• Thu 4/7 Business leadership and communication:
  READING: Technical Debt by Steve McConnell
  
  • What makes a good leader? A poor leader?
  • What motivates business leaders?
  • If you are a leader, what would you like in the people who work for you? What would you dislike?
  • How do you deal with ineffectual subordinates? Peers? Leaders?
  • How do you demonstrate leadership potential when you do not yet have a leadership role?
  • What techniques might you use to effect change in a large organization? What challenges will you face?
• Tue 4/12 Workday
• Thu 4/14 Workday
• Tue 4/19 Wrap Up Discussion: How did your views change
  In today's discussion we will wrap up the semester by talking about what we learned this semester. Revisit the previous discussion topics and contemplate how your answers to these questions have evolved.
  • What specific lessons about designing for evolving requirements have you gained from the class project and discussions this semester?
  • What were the most important of these lessons?
  • How can you apply the lessons you learned to design to guard against difficult requirement changes?
• Thu 4/21 Evolution 4 Oral Presentations.
• Tue 4/26 TBD

Readings I like but couldn't fit into the schedule

• The sad graph of software death by Gregory Brown — How to tell from ticket metrics that you're going to die
• Back to Basics by Joel Spolsky — Shlemiel the painter's algorithm
• Rub a dub dub by Joel Spolsky — An alternative to a code rewrite: a code scrub
• The Joel Test: 12 Steps to Better Code by Joel Spolsky — Cheat sheet of things any good development group should be doing
• Code Complete by Steve McConnell — The whole book is great
• Software Testing by Sarah Heckman — a primer on the fundamentals
• In-depth: Functional programming in C++ by John Carmack — Practicing functional programming can be good even in procedural languages like C++ and time-to-market industries like game development
• The Listener's Bill of Rights by Beryl Pittman — This document covers speaking like the Bill of “Writes” referenced above covers writing
• The case of the 500-mile email by Trey Harris — A quick read about a bizarre email configuration mystery
• The Five Essential Phone-Screen Questions by Steve Yegge — Concisely covers what a good phone screen (or interview) will cover.