Semantic Werks

I’ve done this for a while now, but it occurred to me others might want to check this out:

The SEWORLD mailing list is a venue for most software engineering conference calls, including just about every obscure software workshop you could want. But getting a bunch of mail in your inbox is a bit of a pain. Using Mailbucket, I’ve converted the mailing list responses to an RSS feed which can be viewed, in my case, in Google Reader. I read about 32% of the 23 weekly posts. (I read 100% of the Third Bit posts though!)

Subscribe RSS 2.0

A recent article in IEEE Software magazine studied the impacts of IEEE Software papers from 1984 onwards. The paper, well-hidden behind the cost wall, has a list of the 25 most cited articles in the magazine. I thought I’d reproduce the top 10 here with links to the abstracts, or, where possible, the paper itself. For those unfamiliar with the difference, a magazine article is typically a less-academic summarization of scholarly work, directed at both academics and practitioners.

Credit belongs to Daniel O’Leary, whose work this is.

1. E.J. Chikofsky and J.H. Cross, “Reverse Engineering and Design Recovery: A Taxonomy,” vol. 7, no. 1, 1990, pp. 13–17.
2. M.T. Heath and J.A. Etheridge, “Visualizing the Performance of Parallel Programs,” vol. 8, no. 5, 1991, pp. 29–39.
3. P.B. Kruchten, “The 4+1 View of Architecture,” vol. 12, no. 6, 1995, pp. 42–50.
4. M.C. Paulk et al., “Capability Maturity Model, Version 1.1,” vol. 10, no. 4, 1993, pp. 18–27. [full report]
5. A. Hall, “7 Myths of Formal Methods,” vol. 7, no. 5, 1990, pp. 11–19.
6. B. Boehm, “Software Risk Management: Principles and Practices,” vol. 8, no. 1, 1991, pp. 32–41.
7. R. Prieto-Diaz and P. Freeman, “Classifying Software for Reusability,” vol. 4, no. 1, 1987, pp. 6–16.
8. D.R. Cheriton, “The V-Kernel: A Software Base for Distributed Systems,” vol. 1, no. 2, 1984, pp. 19–42.
9. J.D. Musa, “Operation Profiles in Software Reliability Engineering,” vol. 10, no. 2, 1993, pp. 14–32.
10. C. Potts, K. Takahashi, and A.I. Anton, “Inquiry-Based Requirements Analysis,” vol. 11, no. 2, 1994, pp. 21–32.

O’Leary, Daniel, “The Most Cited IEEE Software Articles,” Software, IEEE , vol.26, no.1, pp.12-14, Jan.-Feb. 2009
URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=4721174&isnumber=4721166

This is part of the MSR Challenge series.

In the midst of my work on the project, I’ve just reported on the details. Here’s the overview.

The MSR workshop is a heavily empirical software engineering conference focused on open-source software repositories. A repository typically contains some or all of the following: source code with revisions; mailing lists; bug trackers; websites; user information; etc. Most of MSR is concerned with the source code, but that’s not (for me) necessarily the most interesting.

In the past 10-15 years, these data sources have grown tremendously, giving us a good opportunity to work with real-world data. Of course, these projects are not representative of the industrial, closed-source world, or rather, we don’t have a good handle on how representative they are.

As an aside, it’s high time someone constructed a software ecosystem guide, because comparing SAP implementations to Gnome music players is meaningless in almost any context I can think of. That’s not to say the open-source code is lower quality; on the contrary, I suspect they may be higher quality than your average corporate website written in VB/ASP.

Every MSR workshop has a challenge component; this year’s challenge is to use projects hosted at Gnome.org as the dataset. There are two challenges: 1) predict growth of Gnome projects (following various theories of software evolution and using different predictive models); 2) report on something ‘interesting’ learned from (all or a subset of) these sources.

I’ve chosen the second challenge, and my next post will go into more detail about the ‘interesting’ thing I hope to uncover. Part of my motivation is to help my own reasoning; the other part is to document the methodology I use for the report.

This series is me blogging my way through the project. The due date is March, so I expect to be reporting at odd intervals until then. And if all goes well, look for me in Vancouver in May!

Three great articles this issue in the Annals of History of Computing:

• Niklaus Wirth on the history of software engineering. Choice quote: “the development of C was a great leap backward”.
• Janet Delve on the role of memory in the history of computing. Choice quote: “too many in our field view the original works of pioneers as sacred, and therefore never to be questioned. Hence accounts of events are seldom challenged, revisited, or reinterpreted.”
• Michael Mahoney on challenges in the history of software. I would argue that software engineers actually do study the mistakes of the past, but perhaps not as systematically as one might like. As Janet Delve mentions, it’s easy to see past projects as irrelevant to current projects (this is the Not Invented Here syndrome in a nutshell). Choice quote: “As historical artifact, software is most valuable in its dynamic form. The historian gains most from seeing how the software worked and from working with it.”

The study of the history of technology is one of great interest to me. I’m particularly interested in software engineering history, namely, how software-mediated technology has arisen, the forces that have shaped the solutions, and so on. I’ve written one paper on this, its subject the history of distributed computing (REST, RPC, CORBA, and others).

There’s a good general-purpose journal: Technology and Culture, which addresses a wide array of topics. There is also the Computer History Museum’s Software Industry SIG, and the IEEE Annals of History of Computing, but that’s about it. The focus also often veers into straight-up narrative, rather than a critical look at how/why certain things evolved.

I think it’s pretty clear why history matters, “those who forget ..” etcetera etcetera. An interview I watched the other day made the case that the inventor of LINQ, Anders Hejlsberg, isn’t ‘inventing’ so much as engineering: applying to Visual Studio and .NET the ideas behind LISP, Python list comprehensions, and so on. Of course this is still creativity in action, as Steve Martin would say. Because Hejlsberg understands his history he is able to leverage it (whether because he is well-read, was there for it, brilliant, or all of the above, I don’t know).

Here is the point, however: good history is not about dates and people, the ‘what happened’ narrative aproach, but ‘why‘: why REST, why Apache took off, why Perl has faded, why WS-* is despised … As you can see, there’s a lot to look at.