The Third Bit

I’m now officially back on the job market—I’ve enjoyed my year of
gainful unemployment, but for a bunch of reasons, it’s time to line up
a steady income. I’m interested in anything that looks fresh (fresher
than porting 100K lines of C++ to 64-bit architectures and debugging
LDAP integration), and that might make the world a better place.

More specifically, I’m interested in the intersection between
social software and software engineering. Can we use ad hoc tagging
to link requirements to test cases and vice versa? And if we do that,
will developers actually start reading and writing requirements? What
about integrating version control and weblogs, so that (for example)
if any of the .rss files in my working copy of a project are updated
when I sync with the master repo, the contents are automatically fed
into my local blog reader? (Jon Pipitone built a prototype of this
for me three years ago; it was kind of cool, but he moved on, and I
never explored it further.)

And what about IM? The first app I run after logging in is email,
but all of my students run an IM client, and are constantly chatting
with each other while working on assignments. If every project comes
with a permanent floating conversation, can we retrofit threading and
searchability so that the content is as useful as email list archives?
Can search engines and/or tagging and/or something else be used to
partition conversations to form clouds of discussion around
requirements, test cases, and so on?

Similarly, some students here fire up SubEthaEdit in a
class and take a single set of notes collaboratively. Does that
scale? Are the authoring patterns the same as they are at Wikipedia and other asynchronous
co-authoring sites? And can we apply the technique to make software
development more efficient?

Wanting to explore these ideas was one of the motivations behind DrProject.
I figured that once we had hundreds of students using basic teamware
routinely, we could start introducing new elements, or modifying
existing ones, to explore new ideas. The other motivation, of course,
was to expose students to the kind of groupware that real software
teams use to coordinate their work. Bug tracking that integrates with
version control that integrates with the wiki and the email list—it
should all be part of everyone’s undergrad experience. If some
enlightened being chose to support it, I think it could have a real
impact on undergraduate software engineering education.

My other long-running interest is transferring skills and knowledge
from gearheads to scientists and engineers. Some time in the mid-90s,
I realized that the real bottleneck in computational science isn’t a
lack of CPU power—it’s the fact that most scientsts have never been
shown how to program. They get a first-year course in C, and (maybe)
another course in numerical methods, and then they’re expected to
discover or invent everything else on their own.

I’m now teaching a
course designed to introduce non-Computer Science grad students to
the programming and data crunching skills they need to work more
efficiently. I think it’s going pretty well, and I’d welcome a chance
to polish and extend it. (The report Jon Udell
wrote for the original Software Carpentry project several years ago is
just one indication of how much more could be done here…) The
problem, of course, is finding someone to fund it…

And then there’s undergraduate teaching. Over the past three
years, I’ve supervised final-year projects for 60 students, who have
worked on everything from extending the DrJava debugger to Internet
censorship monitoring tools, automated testing of J2EE applications,
and 3D visualization of falling rocks. This past summer, I mentored
Chris Lenz‘s project for Google‘s Summer of Code
initiative, and then organized a series of articles about SoC for Doctor Dobb’s Journal. I’d
really like to find a way to scale that up, and get the word out to
students who aren’t already involved in open source. In
particular, I’d like to try to get the ACM and IEEE involved in recruiting and
match-making, and find ways to get students course credit for working
on real open source projects. Google doesn’t seem interested—if
someone else is, I’m easy to find

Finally, there are the blue-sky options: extensible
programming systems, turning JavaScript into a credible
command-line scripting language, and, well, pretty much anything else
fresh that pays my bills without straining my conscience. If I sound
like what you’re looking
for, please drop me a
line.

Uncategorized

A few observations after three weeks of class:

1. A mix of Buckley’s cough syrup and jalapeno peppers clears sinus congestion better than either on its own.
2. Lecturing under the influence of such a mixture is a bad idea: I made of mess of both the first lecture on testing, and the spec for exercise 2. I’m also worried that some students are being left behind, but it seems that these are mostly people with no prior programming experience. As much as I’d like the course to be accessible to them, trying to cater to both complete newcomers, and people looking for a second-level course on software construction, will leave both unsatisfied.
3. That said, the course seems to be going reasonably well: 66 students submitted solutions to Exercise 1, and of those, 48 of the 55 based in Toronto got 80% or better. The graphics are coming along (as soon as I figure out how to stop the backgrounds coming out black when you print from Firefox, I’ll post a fresh set of PDFs), and:
4. The folks at Prince have donated a license for their PDF generation tool, so that I can produce PDFs as part of my regular build of the course notes (rather than having to load pages individually into Firefox, and convert them one by one). I’d owe particular thanks to Michael Day, who helped me straighten out my CSS stylesheets so that the online and print versions would look the same.
5. DrProject is up and running in CSC408 (Software Engineering), CSC488 (Compilers), and CSC494/495 (the project course). Karen Reid and I were very pleased to discover that a significant number of students were creating wiki pages, filing tickets, and generally doing all the things we wanted them to, without being told they had to. We might just be on to something here…
6. October’s Toronto Java Users Group meeting will be held on campus (7:00 Tuesday, Bahen 1180). Hywel Evans will talk about techniques for high performance Java applications; students are welcome to attend. (Remember, you can’t ever have too many contacts when you’re looking for a job…)
7. Several dozen students have submitted articles about their Google Summer of Code projects to the series I organized for Doctor Dobb’s Journal. The first ones should appear in next month’s issue. I’m floored by how cool some of them are, and by how today’s undergraduates take globalization as a matter of course. Those of you still ranting about the evils of offshoring, take note: the next generation simply doesn’t care.
8. And speaking of DDJ, the magazine has run two more opinion pieces I wrote (yes, I get paid for having opinions—why else would I have so many?). The first explains why JavaScript may be the dominant scripting language of 2010; the other, why XML configuration files are the Achilles’ heel of Java, C#, and other sturdy languages.

In other news, Todd Veldhuizen (who is one of the smartest nice guys, and nicest smart guys, I know) has finally finished his paper on Software Libraries and Their Reuse: Entropy, Kolmogorov Complexity, and Zipf’s Law. The abstract says:

We analyze software reuse from the perspective of information theory
and Kolmogorov complexity, assessing our ability to “compress”
programs by expressing them in terms of software components reused
from libraries. A common theme in the software reuse literature is
that if we can only get the right environment in place—the right
tools, the right generalizations, economic incentives, a “culture of
reuse”—then reuse of software will soar, with consequent
improvements in productivity and software quality. The analysis
developed in this paper paints a different picture: the extent to
which software reuse can occur is an intrinsic property of a problem
domain, and better tools and culture can have only marginal impact on
reuse rates if the domain is inherently resistant to reuse. We define
an entropy parameter H::[0,1] of problem domains that measures program
diversity, and deduce from this upper bounds on code reuse and the
scale of components with which we may work. For “low entropy” domains
with H near 0, programs are highly similar to one another and the
domain is amenable to the Component-Based Software Engineering (CBSE)
dream of programming by composing large-scale components. For problem
domains with H near 1, programs require substantial quantities of new
code, with only a modest proportion of an application comprised of
reused, small-scale components. Preliminary empirical results from
Unix platforms support some of the predictions of our model.

There’s a lot of math, but it’s always fun to watch Todd play fireworks with ideas.

Uncategorized