I got mail yesterday from a former student of a friend of mine who has just been told that he has to teach an "Intro to Software Engineering" class this fall to a bunch of third-year undergraduates. He's not an SE guy—his background is operating systems—so he asked me what he should read to get one step ahead of his future students. As regular readers will know, I don't think much of most traditional software engineering books: I've never seen most of what's in them in the real world, and most of what I've needed to know hasn't been in them.
So what did I recommend instead? Here's my list:
- I think that what we prescribe in software engineering should be based on what we actually know from empirical studies, just as it should be in medicine or business, so Making Software is first on the list.
- Karl Fogel's Producing Open Source Software is number two, as it's the best description I've ever read of what good developers do day by day (rather than minute by minute: for that, there's Neal Ford's The Productive Programmer).
- I'm also partial to Henrik Kniberg's Scrum and XP From the Trenches; it's a bit more ideological, but still packed with lots of "been there, done that, here's the t-shirt" advice.
- Reekie & McAdam's A Software Architecture Primer and Rosenberg & Scott's Use Case Driven Object Modeling with UML are the two "traditional" books on my list. They're both slim and uncluttered; the first presents the only useful notation I've ever encountered for describing applications' architectures, while the second explains what the core elements of UML are for and when to use them.
- Michael Feathers' Working Effectively With Legacy Code remains the best book about making large systems manageable that has ever been written. It is also one of the few that acknowledges the reality most students will encounter all too soon—that of tangled, poorly documented legacy systems that cannot just be thrown away.
- Finally, The Architecture of Open Source Applications contains, as far as I know, the only lengthy descriptions anywhere of what software engineering is meant to produce: large, long-lived programs.
I feel a bit uncomfortable listing two books I've worked, but my conscience goes back to sleep when I remind it that my frustration with existing books was a big part of why I started Beautiful Code
, which in turn led to MS
is the most wide-ranging of the three, but the other two are more focused. I hope you find them, and all the others on this list, useful.
Later: someone asked why the Gang of Four Design Patterns
book isn't on this list. The answer is:
- Undergrads don't seem to connect with it—I had much better luck using material Freeman and Freeman's Head First Design Patterns (but not the book itself—most of my students found its format as offputting as I did). My favorite DP book is Olsen's Design Patterns in Ruby, which I blogged about a couple of years ago, but since most of my students don't speak Ruby, I haven't actually taught with it. Now, if Russ ever does a Python version...
- Software design and software engineering are obviously related, but they're not the same thing. In my mind, software engineering is how we produce software, while software design is what software looks like when it's built. Both are important, but trying to cram both into a single course is a disservice to both. (Of course, that's an argument for not including AOSA in this list either...)