# 1: Effective 0320

###### tags: `Tag(sp22)`

Welcome to 0320! Let's start out by exercising our software-engineering muscles. I'd like you to open up the IDE of your choice and write me a sorting program in the language of your choice. You've got 5 minutes starting now!

<details>
<summary>Think, then click.</summary>
Hopefully you didn't immediately start programming. I didn't really give you enough information, did I? I didn't say (among other things):

* what kind of values you would have to sort;
* whether the sort needed to be stable, or in-place, or if there were any runtime requirements; or
* what the input interface should be (do you need to do file I/O or parse a CSV file?)

If you'd written insertion sort, but I needed low worst-case runtime, you'd have had to start all over. Similarly, if you wrote a sort that worked on lists of strings, but I actually had lists of records, you'd have been in trouble.

Get in the habit of **asking questions**: it will save you time and pain in the future.
</details>

From a certain point of view, 0320 is all about lots of different techniques for saving time and pain.

## CSCI 0320: It's More Than a Programming Class

Is that was "software engineering" is? Well, trying to avoid pain is certainly part of it. But there's more to the story. Let me ask you a question: **What makes a piece of software "good"**?

<details>
<summary>Think, then click.</summary>
Here are some possible answers:

* It does what it's supposed to do.
* It's as efficient as it needs to be.
* The problem it solves is the right one.
* It's easy to extend, or for other engineers to use.
* It's understandable to other engineers.
* It has an interface that's understandable to end-users.

There are lots of other reasonable answers! Good software has many dimensions, and most of them involve more than skill at _programming_.
</details>

Don't misunderstand me: you'll all write _lots_ of code in this class. Quite possibly you'll write more code than you ever have before. But just writing a great deal of code is, frankly, _not enough_.

### Being a Successful Engineer

Linus Torvalds, the creator of small open-source projects like Linux and Git, had this to say in a 2020 interview about how he spends his time:

>A lot of open source in general is about communication. And part of it is the commit messages, part of it is just the email going back and forth. Communicating what you're trying to do or communicating why something doesn't work for you is really important.

Wait, that doesn't sound like programming. It sounds like _writing_! He even goes further:

>And so one of the things I hope developers are thinking about, the people who are actually writing code, is not just the code itself, but explaining why the code does something, and why some change was needed...

It sounds like one of the most successful and respected programmers in the world is saying that communication skills, teamwork, documentation, and other "soft" skills are vital in building and maintaining "good" software. And he's right! In fact, I'd argue that there's no such thing as a "soft" skill, just the right skill for the right part of the project.

## Is Software Engineering "Real Engineering"?

|  |
|:--:|
| _A home destroyed in the Merrimack Valley gas explosions of 2018 (Taken by the NTSB, Public Domain)_ |

What caused the explosion that wrecked this house? Well, a few things contributed.

Maintenance workers were replacing some low-pressure gas-supply pipes. These pipes have sensors that detect the gas pressure and report it back to a station that controls gas flow. Unfortunately, this time a sensor didn't get removed before its attached pipe was removed. The sensor (correctly) reported a sudden pressure drop. The station responded by increasing supply. The pressure stayed low. The station increased supply. This continued until the flow was around a hundred times higher than intended for the low-pressure network.

Someone died. Two dozen more were injured. Thousands of people had to evacuate, and many lost their homes.

So, here's a question. What part of the system was at fault?

<details>
<summary>Think, then click.</summary>
The National Safety Transportation Board determined that the fault was with _management_: inadequate planning, slow response, poor documentation, rushed work. But, from a technical perspective, what failed?

* The sensor? But the sensor did what it was supposed to do.
* The station? But the station did what it was supposed to do.
* The workers, or the documentation they followed? Maybe. But the system had no resilience to this sort of error; the failure was town-wide, catastrophic.

The failure was systemic. The sensor didn't distinguish between low pressure and no pressure. The station didn't have a fail-safe, or lacked the information, to detect the difference between a pressure drop, a leak, and bad data. Parts of the system, individually, _weren't safe from bugs in the other parts_.
</details>

There's a lesson here about communication, but also about engineering defensively. It's a theme we'll com

#### Don't get lured into arguments about the wrong question!

But is software engineering "real engineering"? I'd argue the question is ill-typed. What does "real engineering" even mean? But software engineering is real, and can sometimes have real impact. Just ask the people who used to live in that house.

## Setting Expectations for 0320

It's important in any project is to _set expectations early_, and identify areas where expectations might need adjustment. So let's start the semester right. Read the ["setting expectations" document](https://docs.google.com/document/d/1Y1eS9Sg4EoKS8i4XDT9d8GZT-0R7LACsQceu04oM9YE); I'm going to call out a few specific points here.

### Expectations: Overview of the Semester

Here's a general overview of our plans for the semester. All of this is subject to change (e.g., as we finalize the guest-lecture schedule, adjust to student needs, etc.) but it should still give you a high-level idea of what the semester looks like. _Beware: due-dates for term project milestones won't always line up with sprint milestones!_

| Week | Likely Lecture Topics | Lab | Sprint | Term Project |
|-------|--------------------------------------------|-----------------|-----------------------|--------------|
| Jan23 | Onboarding | Onboarding | Sprint 0 | |
| Jan30 | Software Lifecycle, User Stories, Testing | Project Mgmt | Sprint 0 | |
| Feb06 | kd-trees, Bloom filters, strategy pattern | APIs | Sprint 1 | |
| Feb13 | Defensive programming, proxy pattern | Databases | Sprint 1 | Teams Formed |
| Feb20 | HTML/CSS/TS, more proxy pattern | HTML/CSS/TS | Sprint 2 | |
| Feb27 | Concurrency | Async/await | Sprint 2 | Proposals |
| Mar06 | React, **Guest** | React | Sprint 3 | |
| Mar13 | Specification, Random Testing | Discussion | Sprint 3 | Requirements |
| Mar20 | GDPR, Threat modeling | Discussion | Term Project Interlude| Spec/Design |
| Mar27 | Spring Break | | | |
| Apr03 | CI/CD, Beyond Testing | Discussion | Sprint 4 | UI Mockup |
| Apr10 | TBD/Guest | Discussion | Sprint 4 | |
| Apr17 | TBD/Guest | Discussion | **Term Project** | |
| Apr24 | Term Project Hours | | **Term Project** | |
| May01 | Reading Period | | **Term Project** | Individual Component Demos |
| May08 | Reading Period | | **Term Project** | Mgr-Mgr, Pre-demos |
| May15 | Finals Week | | **Term Project** | Demos (starts 14th) |

Note that we've retooled the lecture schedule this year to better match the new project schedule.

When we write "TBD", it doesn't mean we have no lecture topics in mind. Rather, the schedule will solidify as the semester progresses and it becomes clear what students need most to help with their projects. We are also planning guest lectures, one of which (March 10th) is confirmed; the others are still being scheduled.

### What to Expect From Lectures

We work hard to time most lecture topics to cover things that you'll need to use in the current project. However, later in the semester, lectures will begin to cover more general (but important) content. At this point, you'll mostly be working on literally dozens of different term projects -- so the strong coupling becomes weaker over time. This is by necessity! Participate in lecture anyway; we'll be talking about ideas and techniques that _will_ serve you well.

Many lectures, at least once every week, will contain an exercise that you'll submit via a Google form.

We will have the occasional guest lecture. We'll livestream these so that everyone can attend and participate, even if they are remote, and regardless of the current COVID restrictions on campus. On days where we have guest lectures, you can expect some sort of trivial sign-in "exercise" at the start.

### What to Expect From Grading

**Grading has significantly changed versus all prior offerings of 0320.** See our [grading policy](https://docs.google.com/document/d/1AUQaxthtiVrE6hgrX9WbWshicoqqlOjZU1bLNCAogYM/). It's important that you understand how much your success in 0320 depends on **regular, consistent progress and communication**. The course is mandatory S/NC, but that doesn't mean it's an "easy S".

### Expectations: Why **should** you take this course?

You should consider taking 0320 if:

* You want to learn new technical skills, like:
* object-oriented analysis and design;
* front-end development and GUI design;
* dealing with multiple models of concurrency;
* new data structures and algorithmic ideas; and
* new testing techniques.
* You also respect and want to learn skills beyond _just_ the technical, like:
* requirements gathering and working with stakeholders;
* time management and project management;
* working on large projects in a group;
* threat modeling and high-level design;
* compliance-related design considerations; and
* technical writing, documentation, and good specification.

0320 covers a lot of technical material, but it's _not_ a "programming class". Lecture and labs are built to support you in your projects, but the material is not, and cannot be, purely technical.

### Expectations: Why **shouldn't** you take this course?

You should **not** take 0320 if you:

* are not able to commit to weekly mentor check-in meetings;
* are not able to commit to making regular, consistent progress and pushing regularly to a public repository;
* are not willing to review others' code, or have your own code reviewed;
* strongly dislike group work and don't want to write, design, code, review, and present as part of a team;
* aren't willing to accept that the course structure is agile, experimental, and may be adjusted mid-semester.

## Note Card Exercise

* What is a goal you have for 0320?
* What is something you're afraid of in 0320?
* What is something you need to succeed in 0320?