The fourth lecture on Python for the Software Carpentry course is now up. It covers sets, dictionaries, and a little bit of algorithmic complexity. Comments and criticisms are very welcome.
And if that’s too serious for year, check out the web site for the Waterfall 2006 conference 
.
I have taught at least one of each of these. I have also, at various times, been at least half a dozen… Depressing, though, that 25 of the 26 characters are male.
Adam Goucher on the role of a product manager. As he says, this is one of the key positions (maybe the key position) in a software development group, but it’s not one that’s discussed often, if at all, in software engineering classes.
It used to be the introductory lecture on testing; now it’s more of an introduction to quality assurance from a programmer’s point of view. It’s changed even more than the style lecture; comments and corrections would be very welcome. (And yes, I know, the diagrams are missing…)
The Software Carpentry lecture on programming style has been revised. Comments on this would be particularly welcome, as it’s substantially different from what I delivered last fall.
The third lecture on Python for the Software Carpentry course has been posted; comments and criticisms are invited and appreciated.
This posting from the folks at F-Secure compares the structure of the first PC virus, Boot/Brain.A (which recently celebrated its 20th birthday) with that of the more recent W32/Bagle.AG. Coincidentally, multi-drug resistant tuberculosis is on the rise. Having just reviewed Nancy Forbes’ Imitation of Life: How Biology is Inspiring Computing, I have to wonder: does the existence of anti-virus programs produce tougher computer viruses in the same way that more powerful drugs drive the evolution of real ones?
It will probably never be a popular party game, but here goes:
#1: Ivan Sklyarov’s Puzzles for Hackers. This is laid out like most other programming puzzle books, except all the puzzles in this one involve breaking codes, hiding files (or finding ones that have been hidden), and so on. Working through them is very much like riding in an original World War II Jeep: bumpy, often bone-jarring, and exhilirating. I haven’t had this much fun with a book in a while; recommended.
#2: Forbes’ Imitation of Life. An increasing number of computer systems draw on biological analogies: entire businesses are now built around self-healing systems, genetic algorithms, and fighting viruses. At the same time, computing has given us new ways to look at living organisms—it’s no longer considered strange, for example, to ask what and how a cell computes. This survey, which is written at the same level as the typical Discover article or Nova episode, does a good job of tying these topics together. The prose flows smoothly, the illustrations are nicely chosen, and the author’s enthusiasm for the subject comes through clearly. Also recommended.
#3: Hunley’s Using Open Source Web Software with Windows. This is one case where first impressions are correct: everything in this book can be found on the web fairly easily. Hunley’s contribution is to pull it all together, organize it, and fill in some of the potholes that often trip up novices. If you already have Apache and PHP running on your XP machine, you’re well beyond what this book covers; if you’re about to do it for the first time, this may save you considerable grief.
#4: Pugh’s Prefactoring. While well-written, it struck me as a case of the whole being less than the sum of its parts. Pugh touches on a wide range of developer-oriented issues, ranging from eliciting requirements to the right way to document to aspect-oriented programming. The whole is supposed to be tied together by a running example (a CD rental business), but it just didn’t work for me: every single piece of advice is well-founded and worth following, but I never felt like I knew where the author was taking me.
#5: Moyle and Kelley’s Cryptographic Libraries for Developers. Having worked on a security product for several years, I firmly believe that the real reason so much software is insecure is that the APIs and documentation developers have to wade through makes security several times harder than it ought to be. I therefore had high hopes for this book, both because of its cross-library approach, and because it promised to cover the context in which crypto libraries are used. Unfortunately, the first third of the book nearly put me off it—paragraphs that run for a page and a half, and poorly commented five-page code samples, are not the way to engage a reader’s interest. Once past that, though, the book does pick up and offer a well-informed look at several major libraries. I think there’s room for improvement, but until then, this one is worth having on your shelf.
Eric Hunley: Using Open Source Web Software with Windows. Charles River Media, 2006, 1584504307, 334 pages.
Ed Moyle and Diana Kelley: Cryptographic Libraries for Developers. Charles River Media, 2006, 1584504099, 464 pages.
Ken Pugh: Prefactoring. O’Reilly, 2005, 0596008740, 220 pages.
Ivan Sklyarov: Puzzles for Hackers. A-List, 2005, 1931769451, 336 pages.
I read these two books on project management back to back: at my partner’s request, I finally uninstalled Homeworld—which is still the best game ever—and that left me with lots of time to catch up on my reading. They made an interesting pair, and the differences between their authors’ positions says a lot about where the software industry is today.
Stellman and Greene’s book is the more conventional of the two. Their aim is to put everything you need to know to run a small- to medium-sized software project between two covers. After a short introduction, which lays out the principles they believe successful managers should follow, the book is divided into two parts. The first, “Tools and Techniques”, includes all the usual suspects: planning, estimation, schedules, reviews, requirements, design and programming, and testing. While their language is sometimes a little highfalutin’ (“Wideband Delphi estimates”, anyone?), the advice is all solidly grounded and eminently practical. It’s all been said before, but as covers go, this is as good as The Clash’s version of “I Fought the Law”.
The book’s second half is about the act of management. Its chapter titles tell the story: “Understanding Change”, “Management and Leadership”, “Managing an Outsourced Project”, and “Process Improvement”. In my experience, these topics are nearly impossible to teach in book form: the only way to learn them is to have someone coach you while you’re doing them. That said, Stellman and Greene do as good a job as anyone, while thankfully avoiding anything that smells of Tony Robbins. It’s a solid book, well researched, and definitely worth reading.
Stepanek’s Software Project Secrets is a marked contrast. The tag line on the front cover is, “Resolving the conflicts between software development and project management”, and it’s clear from page one that the author (a) has been caught in this particular vise more than once, and (b) really wants to find a better way to do things. Drawing on both his personal experience and the published literature, Stepanek gives twelve reasons why software is different. Some of them are inarguable: software is complex and abstract, and construction is design.
But then there’s #3: “Requirements are incomplete”. Stepanek treats this as being intrinsic to software development, when in fact it is merely common (bad) practice. His own point #11, “Change is considered easy,” is the reason, but shifting sands are no more inescapable in software than they are in civil engineering. “What happens if the scope can’t be completely defined?” he asks, as if it were any easier or more natural for architects to get specs from their clients than it is for programmers.
Similarly, while Stepanek refers to many of the classic works in software engineering, he seems to have missed most of what’s appeared in the primary literature in the last ten years. New journals like Empirical Software Engineering have both reflected, and encouraged, new studies of what actually works and doesn’t—studies that are methodologically sounder than many of their predecessors—and I think they ought to be required reading for anyone writing about software engineering today. I share Stepanek’s sense of frustration, but think that software engineering isn’t as special as it is often convenient for software engineers to believe.
George Stepanek: Software Project Secrets: Why Software Projects Fail. Apress, 2005, 1590595505, 165 pages.
Compilers and operating systems have been a standard part of computer science education for more than thirty years, but the engines that allow the output of the first to run on the second have always fallen through the cracks. With all of today’s hot languages now running on some sort of virtual machine, it was inevitable that textbooks on the subject would start to appear.
At first glance, these two identically-named books are polar opposites. The first, by Iain Craig, is slim and personal: it comes across as a tidied-up version of the author’s personal notes on twenty-plus years of virtual machines. Its layout is dense (“tombstone TeX”, as a friend in the publishing industry would say), and a large part of the book retraces the design of a toy VM created by the author.
The second, by Smith and Nair, is easily three times the volume. It attempts to be a comprehensive survey of VMs, covering everything from language execution engines to tools for virtualizing one operating system on top of another. There’s a lot more whitespace, many more diagrams, and copious references to present-generation industrial-strength systems.
What these two books have in common is that neither particularly satisfied me. They’re both solidly written, but not engaging; Craig contains reference material that could have been left online, while there are important topics that Smith and Nair should either have devoted an entire chapter to (with sample code!), or left out entirely. If I had to pick one for a course, I’d probably use Smith and Nair, but this field is still waiting for its “Dragon Book”.
James E. Smith and Ravi Nair: Virtual Machines. Morgan Kaufmann, 2005, 1558609105, 638 pages.
Recent Comments