“If you only have time to read one book—make time to read two.” Here’s a devil’s dozen to keep you occupied at the cottage this summer…
- Project Management
- Berkun’s The Art of Project Management and Stellman and Greene’s Applied Software Project Management.
- Development
- Doar’s Practical Development Environments, Feathers’ Working Effectively with Legacy Code, and Fogel’s Producing Open Source Software.
- Future Big Ideas
- Oakley’s Monad and Zeller’s Why Programs Fail.
- General Non-Fiction
- Armstrong’s The Battle for God, Beinart’s The Good Fight, Hochschild’s Bury the Chains, Weiner’s Time, Love, Memory, Whitfield’s Life Along the Silk Road, and Zamoyski’s cynical, yet entertaining, Holy Madness.
- Fiction
- Bishop’s The Etched City, Furst’s The Polish Officer, McDonald’s The Broken Land, Mitchell’s Cloud Atlas, and Willis’s Bellwether.
Books
From the abstract of Arisholm et al’s “The Impact of UML Documentation on Software Maintenance: An Experimental Evaluation” (IEEE Trans. Soft. Eng, 32/6, June 2006):
Results show that, for complex tasks and past a certain learning curve, the availability of UML documentation may result in significant improvements in the functional orrectness of changes as well as the quality of their design. However, there does not seem to be any saving of time. For simpler tasks, the time needed to update the UML documentation may be substantial compared with the potential benefits, thus motivating the need for UML tools with better support for software maintenance.
Note that “…thus raising the question of whether UML is worth using at all” isn’t presented as an option… 
Uncategorized
I used to maintain a list of books that I wished someone would write, so that I could review them for Doctor Dobb’s Journal. (It even happened once, which just goes to show that sympathetic magic actually works.) Rebecca Wirfs-Brock’s latest article, “Designing for Recovery”, reminds me that the one I want most still isn’t on the shelves. I’d really, really like someone to write a book on error handling and recovery: something like 25-30% of the code in large applications is devoted to this, but no one is ever taught how to do it systematically. As distributed systems become the norm, partial failure and fault tolerance are becoming everyday issues; if anyone out there wants to be rich, famous, and popular, there are worse places to start than writing this book.
Books
The July’06 issue of IEEE Software has an excellent article called “Agile Software Testing in a Large-Scale Project”. It presents data on what happens when you introduce some XP practices into a large software project; as the authors say, “…this is the most comprehensive data set from an actual project using agile quality practices that has published its results to date.” Very worth reading — it’s unfortunately not free, but you can buy a copy online. I’ve been sceptical of the claims made by XP’s more outspoken advocates; it looks like I may have to admit I was wrong.
Research
Some of these are so funny, they have to be true.
Uncategorized
Four people have sent me links to this research in the last 24 hours. It claims that:
- there are two kinds of people: those who can push symbols around without concern for their “meaning” (or lack of it), and those who can’t;
- the former can learn how to program, while the latter will always struggle with it; and
- a simple test can determine which group someone falls into.
I first came across this work in February, while taking Steve Easterbrook‘s course on empirical methods in software engineering. The original version had been basted in sarcasm and breaded with scorn; it was entertaining to read, but I was sceptical about both the methodology and the conclusions. The current version isn’t quite as much fun, but makes the case more strongly. Steve and some local grad students are going to try to reproduce the experiment locally this fall; I’m very eager to see the results.
Research
An article from researchers at UBC in the latest issue of IEEE Software analyzes how developers actually use Eclipse. The top five views from the standard distribution are Package Explorer, Console, Search, Problems, and Variables; the Declaration view was never used by their test subjects, even though it’s displayed by default for Java development. (This is actually better than you’d expect, given studies done by the Standish Group showing that 40% or more of the features in large programs are never used.)
We’d like to do studies like this with DrProject, to find out which pieces students actually use, and which they ignore. Tagging, for example: will people who use Flickr and the like take an extra few seconds to tag tickets and wiki pages, or will they not bother? And if they do tag, will it correlate with better marks? We couldn’t find any patterns in CVS usage that correlated when we looked two years ago, which surprised us; we eventually blamed that on the fact that students were climbing the learning curve, but we really don’t know.
Coincidentally, I just finished another paper by Greg Watson and Nathan DeBardeleben, both of Los Alamos National Laboratory, on developing scientific applications using Eclipse. This one appeared in Computing in Science and Engineering; it’s an excellent study of how to customize tools to respond to a particular community’s needs. I’ve been swapping mail with the authors for the last few days, trying to get some more insight into why scientific programmers are often resistant to adopting new tools and processes; if we reach any conclusions, I’ll post ‘em here .
Research
All very tentative, but here are some of the options:
Add more features to RedInk, the online marking and code review system we’ve built over the past twelve months. (Now full)- Building a plugin for Blackboard to calculate and display statistics on the grades being given out by TAs in large courses (Java programming, lots of integration, customer is profs at U of T).
- Building a map-based visualization of data about theatre performers and playwrights in Shakespearean England for the Drama Dept. and the library (DreamWeaver, web programming, GIS).
- Adding new features to DrProject (Python web programming). There are lots of possibilities here, ranging from user-centered views to a progress dashboard to continuous integration tools and real-time documentation generation.
- Extending Languify, an open source web-based tool for managing translation and internationalization (Ruby On Rails, web programming). The customer here is a local software startup called Savvica; a student has built a first version this summer, and there’s a lot of interest.
- Help the folks at CAISI integrate hospital information systems to help the homeless. This one would mostly be Java; it’s a very good cause.
- Work with Digital Ketchup to build a REST web services interface to a tool that combines data from email and customer relationship management software.
- Add some features to BlogScope to integrate with other data sources, and do some of the AI and pattern matching more efficiently.
- Sort out the mess that is date/time representation in Python’s database interface libraries.
If you’re at U of T, have at least two 300-level courses in CS, and a good GPA (3.0 or higher), I’d like to hear from you…
Uncategorized
We are very pleased to announce the release of DrProject 1.0. For those of you who aren’t regular readers , DrProject is a web-based software project management portal specifically tailored for classroom use. Like its predecessor, Trac, it integrates Subversion with a wiki, a simple bug tracker, and milestones. Unlike Trac, it supports multiple projects out of the box, relies on the underlying Unix system for authentication, and provides per-project mailing lists with whitelisting. DrProject is already in use in classes at the University of Toronto, and is being trialed at other educational institutions.
We’d like to thank the University of Toronto, Perforce, the Jonah Group, IBM, and the Natural Sciences and Engineering Research Council for their support. We’d also like to thank everyone whose hard work made this release possible. As they say: w00t!
(Please note: the 1.0 release is rather slow due to some “features” of the wiki-to-HTML converter. These will be corrected for the 1.1 release, which we expect to make available in about four weeks.)
DrProject
Recent Comments