The precursor to this course (CPSC 220) had the word “programming” in its title. This one, in contrast, features the words “analysis” and “design.” Is this just semantics, or is something deeper implied by this choice of terms?

The wording was deliberate, and in many ways it’s a matter of scale. When we talk about programming, we think of individual lines of code that are assembled to create a function or a loop. But the word design connotes something larger: a system complex enough that it requires advanced planning and organization to keep it under control. Programming is tactical: your focus is on what’s in front of you and on getting the details right. Design is strategic: your focus is on the big picture and on outlining a structure into which all those details can fit together.

Although at this point of your career you’ve acquired some essential programming expertise, two important things have probably been missing from your experience: (1) big projects, and (2) team projects. The early courses in any computer science curriculum focus on tiny programs that you complete on your own. They may not have seemed tiny at the time, but if you compare them with anything you use on a daily basis — Insta, Google Docs, Firefox, YouTube, Fortnite — you’ll realize just how small they really are.

It turns out that once a software project reaches a particular size, it undergoes certain changes that make it unlike anything smaller. That’s not only because of increasing complexity, but also because it’s now too big for any one person to hold in their head at once. You now have to depend on an intuitive design and accurate documentation to have a fighting chance of writing the code correctly. This is an utterly new kind of experience.

Working cooperatively with others is also a new kind of experience. You have to depend on someone else’s code working right in order for yours to work right. This is nearly always how software development works in the real world, and gaining practice with this paradigm will be a primary focus of this class.

When these two pieces of the puzzle are in place, you will have acquired an important level of mastery. By the end of this course, you will know enough about how software is really built to be professionally hire-able. You should be able to walk in to your average development team as a ground-floor software engineer and basically know what the heck you’re doing. It will be challenging, but also worth it in the long run. So hang on and enjoy the ride.