Thu 1/11. Introduction

• Course overview slides
• Minor: Pick two discussion leads and four language presenters for next session.
• Pick teams and get started!

Tue 1/16. Programming Languages and Frameworks

• Beating the Averages by Paul Graham (the Blub Paradox)
• Your group's first design decision will be which language and framework to implement your project in.
• Part 1: Language bootcamp: To help, a number of students are asked to research a language/framework and deliver:
  1. a 4-minute intro presentation, and
  2. a written one-page quick-start containing links and information for any team that might wish to deploy it.
  To ensure good diversity, I'd like to at least see solutions based around:
  • NodeJS (Meteor, MeanIO, Sail, Koa, Express, etc.),
  • Python (Django, Flask, Pyramid, etc.),
  • Ruby (Rails), and
  • a Microsoft language (e.g. C#/ASP.NET).
  Additional options are encouraged, including esoteric ones like Go, Rust, Scala, OCaml, Squeak, Scheme, etc. You can do Java if you really want. This part is strictly technically focused; discussion of the merits of the languages will take place in part 2.
  
  Student notes/materials:
  • Parker Pearson - Play (Scala / Java)
  • Chad Coviel - Django
  • Walker Eacho - NodeJS
  • Mitchell Kim - Rails
  • Geng Sng - NodeJS
  • Ryan St Pierre - React
  • Lucia Martos Jimenez - Django (hard copy)
  • Aditya Srinivasan - OCaml
  
  
• Part 2: Tradeoff discussion: After the brief technical intros, our first class discussion will focus on topics to consider in making your language selection. Here are some concrete discussion points to consider:
  • What is the "Blub paradox"? Do you suffer from it?
  • What language features make a programming language "Good"? Why?
  • How do the relative importance of those features change in different situations?
  • Consider a handful of programming languages which you know or which were covered—how well (or poorly) do these languages provide the features you described above?
• NOTE: Teams will be presenting their project management plan in two days...

Thu 1/18. Project management

• Evidence-Based Scheduling by Joel Spolsky
• In my experience, bad planning and logistics is just as likely to sink your project as design issues. Let's fix that.
• Each team must identify and report on a tool and/or technique to address each of the following issues:
  • Project dependencies, timeline, and opportunities for parallel effort (e.g. Gantt chart?)
  • Bug/task tracking and assignment
  • Source code control and governance (branching, merging, code review, deployment, etc.)
  You don't necessarily need a heavyweight tool for each thing; just be able to describe how you'll address them.
• Let's discuss some of the planning issues you may encounter.
  • What are ALL the steps that will go into a release (evolution) of your softare?
  • Is it worth anything to know you're behind schedule? What can you do with that information?
  • How could a project's execution be "inefficient"? How can this inefficiency be detected and corrected?
  • The above practices are mostly about improving efficiency, but how might they also improve the quality of the final product?

Tue 1/23. Workday

• Stand-up status meeting (quick!)

Thu 1/25. Good Design: What is it?

• Guest panelist: Daniel Holmes, Senior Software Engineer – Development Tools and Services, NetApp
• Basics of the Unix Philosophy from The Art of Unix Programming by Eric S. Raymond
• Sections 5.1 and 5.2 of Chapter 5 of Code Complete by Steve McConnell
• 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?
• What is essential complexity? Accidental complexity?
  • How do we deal with the essential complexity?
  • What might lead us to create accidental complexity?
  • Consider the following quote from Neal Ford: "It's the duty of the architect to solve the problems inherent in essential complexity without introducing accidental complexity." How can we do this?
• 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, etc. In the latter, 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 1/30. Workday

• Stand-up status meeting (quick!)

Thu 2/01. Effective professional presentations and technical demos

• Guest panelist: David Klem, Strategic Solutions Architect, Dropbox.
• The Listener's Bill of Rights by Beryl Pittman
• How to pull off a slick tech demo (in 5 easy steps) by Martin Kleppmann
• You're going to present your first evolution soon. Some questions to ponder:
  • You've certainly born witness to bad presentations...what made them bad?
  • What defines "professionalism" in a presentation?
  • What are some techniques and tricks to help give a smooth presentation?
  • In what ways might a speaker lose credibility?
  • If you show up to do a presentation and you can't connect to the projector, do you look like a giant fool? (HINT: yes.) What can be done to prevent this?
  • Public demos tend to fail with almost magical regularity. What can you do to mitigate this risk?

Tue 2/06. Evolution 1

• Oral presentations
• Due today by 8am 11:59pm:
  • Code for this evolution should be submitted
  • This same code should be kept deployed on a production machine
  • Your demo meeting should be scheduled
• (note: future evolutions will be due at 8am sharp)

Thu 2/08. Evolution 1 Reflection

• Each team should come prepared to discuss:
  • What parts of your design do you think will set you up well for the future? Why?
  • What parts of your system are you most worried about going forward? Why?
  • How is your project/software management methodology working? Have you had to evolve it?
• After hearing everyone present, we will discuss tradeoffs between different teams' approaches.

Tue 2/13. Workday

• Stand-up status meeting (quick!)
• Due today by 8am:
  • Project report for evolution 1

Thu 2/15. Testing and Debugging: two separate things

• Guest panelist: Michael Peters, Senior Software Engineer, Cisco.
• Software Testing by Sarah Heckman — a primer on the fundamentals
• The case of the disabled logins — an interesting diagnosis of a malfunctioning Linux-based kiosk
• Testing: Systematic 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?
• Debugging: 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 2/20. Workday

• Stand-up status meeting (quick!)

Thu 2/22. User interface design

• User Interface Design Basics from usability.gov
• (Just skim) User Interface Elements from usability.gov
• Effective Visual Communication for Graphical User Interfaces by Suzanne Martin (from 1995).
• 7 Rules for Creating Gorgeous UI (Part 1 only) by Erik D. Kennedy.
• What is the motivation for studying user interface design?
• Have you ever seen a "bad" UI? What made it bad? What are the risks of bad UI design?
• How should your software architecture inform your UI design? How might it inadvertantly influence UI design?
• What design changes have you made to your UI during or since evolution 1? Why?
• How can a UI support both novice and advanced users simultaneously?
• Given the subjective nature of aesthetics, how can we have "rules" in UI design? What rules might change over time, and which might be timeless?
• What is accessibility? How accessible is your software right now?

Tue 2/27. Evolution 2

• Oral presentations
• Due today by 8am:
  • Code for this evolution should be submitted
  • This same code should be kept deployed on a production machine
  • Your demo meeting should be scheduled

Thu 3/01. Evolution 2 Reflection

• Each team should come prepared to discuss:
  • Looking back on what you considered your strengths...were they strengths?
  • Looking back on what you considered your weaknesses...were they weaknesses? What did you do about it?
  • What parts of your design do you think will set you up well for the future? Why?
  • What parts of your system are you most worried about going forward? Why?
  • How is your project/software management methodology working? Have you had to evolve it?
• After hearing everyone present, we will discuss tradeoffs between different teams' approaches.

Tue 3/06. Workday

• Stand-up status meeting (quick!)

Thu 3/08. Teamwork: impact of teamwork on programming

• Guest panelist: Henry Vail, Technical Director for Software-Defined Infrastructure, Lenovo.
• Chapter 1 of How to Win Friends and Influence People by Dale Carnegie
  (and in the interest of time, you'll be forgiven for just skimming some of the more lengthy anecdotes...)
• Today's discussion will focus on programming as a team effort:
  • What benefits does team programming have?
  • What difficulties does it introduce?
  • How does leadership/governance work on your team, i.e., how are decisions made and disagreements resolved?
  • How should you deal with a peer who seems discouraged or you feel may be having trouble contributing?
  • How would your approach differ with a peer who you feel could be working harder?
• Due today by 8am:
  • Project report for evolution 2

Tue 3/13. Spring Break (no class)

Thu 3/15. Spring Break (no class)

Tue 3/20. Maintainability and Refactoring vs. Rewriting

• Guest panelist: Rebecca Register, Kernel Software Engineer, NetApp.
• Things You Should Never Do, Part I by Joel Spolsky
• 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 3/22. Workday

• Stand-up status meeting (quick!)

Tue 3/27. Evolution 3

• Oral presentations
• Due today by 8am:
  • Code for this evolution should be submitted
  • This same code should be kept deployed on a production machine
  • Your demo meeting should be scheduled

Thu 3/29. Evolution 3 Reflection

• Each team should come prepared to discuss:
  • Looking back on what you considered your strengths...were they strengths?
  • Looking back on what you considered your weaknesses...were they weaknesses? What did you do about it?
  • What parts of your design do you think will set you up well for the future? Why?
  • What parts of your system are you most worried about going forward? Why?
  • How is your project/software management methodology working? Have you had to evolve it?
• After hearing everyone present, we will discuss tradeoffs between different teams' approaches.

Tue 4/03. Workday

• Stand-up status meeting (quick!)

Thu 4/05. Effective technical writing and software documentation

• Guest panelist: Dr. David L Kaminsky, Senior Technical Staff Member. IBM.
• The Bill of “Writes” by Beryl Pittman
• Writing: Your second evolution 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.
• Documentation: most programmers hate writing it, but wish they had more of it to read...
  • How much documentation has your team written? What form does this take? Are you happy with it?
  • What makes good documentation?
  • Documentation takes time, but what are some ways in which it might save more time than it takes?
  • Can good code documentation improve the quality of the product from the user's perspective?
• NOTE: Assign subsections of reading for next session's discussion.
• Due today by 8am:
  • Project report for evolution 3

Tue 4/10. Business stuff: leadership, communication, budgeting, and politics

• Guest panelist: Craig Chadwell, Product Manager, Lenovo
• Technical Debt by Steve McConnell
• A assigned subsection from How to Win Friends and Influence People by Dale Carnegie
  (one of the set {3.1-3.12, 4.1-4.9}. )
• Capex vs. Opex, Diffen.com
• Whether you're headed to a big corporation, a small startup, or an academic role, it is certain that non-technical business issues will "intrude" on your work. In my experience, once you pass a certain level of technical expertise, your career will likely be defined by your understanding of leadership, communication, budgeting, and politics.
  • What makes a good leader? A poor leader?
  • How do you demonstrate leadership potential when you do not yet have a leadership role?
  • How might someone fail to convince others even when they're right?
  • What motivates decision makers in a business?
  • How could software design decisions affect the budgeting of a software project?

Thu 4/12. Workday

• Stand-up status meeting (quick!)

Tue 4/17. Evolution 4

• Oral presentations
• Due today by 8am:
  • Code for this evolution should be submitted
  • This same code should be kept deployed on a production machine
  • Your demo meeting should be scheduled

Thu 4/19. Overall Reflection

• Each team should come prepared to discuss:
  • Looking back on what you considered your strengths...were they strengths?
  • Looking back on what you considered your weaknesses...were they weaknesses? What did you do about it?
  • How did your project/software management methodology work?
• 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?

Tue 4/24. Party

• Party
• Due today by 8am:
  • Final project report
    (Yes it's lame that the final report is due on the day of the party, but come on, it was either that or make it due earlier...)