Hi - I'm Greg Wilson, and this short talk describes two new open access resources you might want to use in undergraduate software engineering classes.
Here's how it all started. Back in the early 2000s I taught a course on software architecture three times at the University of Toronto and then told the department they should cancel it. The problem was a lack of material: between them, the eight books I had on my shelf with "software architecture" in the title spent a total of less than 30 pages describing actual systems. They explained how to gather architectural requirements, how to maintain them, and how to communicate them, but didn't show readers what real systems looked like.
In frustration, I mailed 200 programmers and asked them to write a chapter each describing the most beautiful piece of software they'd ever seen. We wound up with 34 contribution, which were published as a book called Beautiful Code. It won a Jolt Award and raised quite a bit of money for charity, but it wasn't useful as a textbook: the pieces of software contributors described ranged in size from a few lines of code to multi-million line systems, and required far more background knowledge than undergrads were likely to have.
Our second attempt was a pair of books called The Architecture of Open Source Applications. The entries were much more uniform in level, but the contributors used such a wide range of languages that once again most students would have struggled to follow along. On the upside, all of the content was (and is) open access.
The irony is, I learned most of what I know about software design from a series of books that avoided all of these problems. The trilogy that Brian Kernighan and colleagues wrote in the early 1980s didn't just teach people C and Unix: they taught my generation how to think about programming by showing us how to build the tools we used to program.
The material covers twenty tools, ranging from a very (very) simple version control system to a browser layout engine, an interactive debugger, and a style checker.
Each entry is short enough to cover in one or two lectures. Together, they introduce some common design patterns, show students how to test complex systems by mocking or stubbing components, and introduce them to tools they should probably be using anyway.
There are lots of starting points for homework exercises, mostly of the form "add this feature to tool X" or "build a very simple version of tool Y from scratch". If your students do the latter, we'd be very happy to include their work - with full attribution - in Volume 2. And if you think of a tool that we haven't covered but should, like a fuzz tester or accessibility auditor, please dive in.
Meanwhile, whenever I run into one of my former project students, they tell me that the most useful thing I taught them wasn't about code: it was about how to work in a team. I think this is more important with each passing year: we used to say, "Move fast and break things," and while I don't know if we did the former, it's pretty clear at this point that we've done a lot of breaking.
The second book, Building Software Together, is what a small team of undergrads needs to know to get through their first semester-long project. It talks about version control and continuous integration, but it's mostly about the human side of software engineering. How do you run a meeting? How do you review someone else's code? How to handle deadlines when you're juggling assignments in several different courses whose lecturers don't seem to talk to each other?
I'm still dissatisfied with some parts of this book. In particular, I don't think the chapters on security and inclusivity are going to persuade someone who doesn't already care about these things that they should. I've taught ethics to engineers, and I think that in a lot of cases, they tune out while we're talking, tell us what they think we expect to hear, and carry on as before. If you or your students can think of better approaches for these important topics, please let me know - I'm happy to rewrite.
To wrap up, these two books don't have to be used together, but they are designed to complement one another. They are both free to use under a Creative Commons - Attribution - NonCommercial license, which means you can copy or modify them however you want as long as you link back to the originals and don't try to make any money from it. (If print editions do appear, 100% of the royalties will go to support the Red Door Shelter in Toronto.) Contributions are very welcome, and all contributors will be acknowledged.
...and you can reach me at firstname.lastname@example.org. Thank you for listening.