More recent academic reading:
Luo, Chen, and Yu: "Toward a progress indicator for program compilation." Software: Practice & Experience, 37:909-33, 2007. It turns out that building an accurate progress bar for compilation is a lot harder than you'd think. This is a good example of the kind of "post mortem" that I think is the best way to teach software design.
Cickovski et al.: "From Genes to Organisms Via the Cell: A Problem-Solving Environment for Multicellular Development". Computing in Science & Engineering, July/August 2007. Describes CompuCell3D, a multiscale simulation of how cells turn into organisms. This is structural biology's equivalent of global climate models, and equally complex.
Dieter and Dietz: "Designing a Cluster for Your Application". Computing in Science & Engineering, July/August 2007. Describes a set of rules for designing a Linux cluster that comes complete with a web interface. I'm old enough to remember when this stuff was hard...
Buschmann, Henney, and Schmidt: "Past, Present, and Future Trends in Software Patterns". IEEE Software, July/August 2007. An interesting---and balanced---summary of where design patterns have been, and what influence they've actually had.
Manolescu, Kozaczynski, Miller, and Hogg: "The Growing Divide in the Patterns World". IEEE Software, July/August 2007. Everybody's heard of patterns, but only a minority of developers actually design with them, or know of any beyond the two dozen from the Gang of Four book.
Cleland-Huang et al: "Best Practices for Automated Traceability". IEEE Computer, June 2007. A brief introduction to the idea of automated traceability (basically, a two-way google to connect requirements documents to code and tests), followed by a description of a tool called Poirot:TraceMaker. This is the standard heavyweight approach that assumes people will write and update specs that actually mean something. (And isn't it ironic that when I tried to check the reference, IEEE Computer's web site was down with an internal server configuration error?)
Telang and Wattal: "An Empirical Analysis of the Impact of Software Vulnerability Announcements on Firm Sock Price". IEEE Trans. Software Engineering, 33(8), August 2007. Does announcing a security hole in your software affect your stock price? The answer is "yes", but the average amount is only 0.6% (though it's worse in highly competitive markets, or if you're a small company).
Porter et al.: "Skoll: A Process and Infrastructure for Distributed Continuous Quality Assurance". IEEE Trans. Software Engineering, 33(8), August 2007. Does it take several hours to run your whole test suite? Do you need to run it on dozens of different platforms? Is your development team scattered across all 24 time zones? The Skoll process and tool may be what you're looking for.
And on a completely different note: if I loaned you my copy of Jack of Shadows or After Man, could you please let me know? My other books miss their friends...