Elsevier Journals for Software Engineering
Given the kerfuffle over Elsevier (see Michael Nielsen’s summary of affairs), I thought it would be instructive to list the Elsevier titles which cover my field of software engineering and information systems, in case people wanted to decide for themselves whether to support this corporation with free labour.
I had some doubts about publishing this list and making my views known, since being on the editorial board for journals like these helps one’s CV. But then, at some point you have to decide whether the larger issues of open access and relevance are important to you. In any event, these venues are, I’m convinced, making it very difficult for academics like me to have meaningful impact on the practice of software engineering. If it will cost a reader 35$ to read my article, I might as well not bother. Which seems to be what the low impact factors are telling us, anyway. (I’m not sure why I linked to them …)
- Journal of Systems and Software – IF 1.277 – Editor Hans Van Vliet
- Science of Computer Programming – IF 1.282
- Information and Software Technology – IF 1.507 – Editor Claes Wohlin
- International Journal of Human Computer Studies – IF 1.600
- Advances in Engineering Software – IF 1.004
- Applied Computing and Informatics – no impact factor, run by the King Saud University (see Crooked Timber for more on Saudi universities).
- Data & Knowledge Engineering – IF 1.717
- Information and Management – IF 2.627
- Information Systems – IF 1.595
- International Journal of Human Computer Studies – IF 1.600
The Research Works Act
Here is the text of an email I sent to the President of the ACM, Alain Chesnais (achesnais@acm.org) and the director of the ACM’s lobby effort, Cameron Wilson (cameron.wilson@acm.org). For more context, there is a good article in the Guardian.
I am writing to express my concern that the ACM is tacitly supporting the Research Works Act. I have read the blog post [1] of M. Chesnais, the ACM president, and to me it reads much like he is an ostrich putting its head in the sand. This act (and others like SOPA) will have major negative implications for research in the computer science disciplines.
That the ACM is international, or that the President is not American, is immaterial. Elsevier is likewise ‘international’, and that has not stopped it from making major financial efforts to influence this legislation. The reality is that US policy and the US market is so important that it has international significance.
I would like the ACM and its affiliates to publicly disavow the Association of American Publishers by cancelling membership. I would also like a public statement to the effect that the provisions of the RWA are anti-science and anti-progress – in short, contravene (at least) Article 2 of the Constitution, which states the ACM’s purpose is to foster the “open interchange of information”.
This issue is so important that neutrality is not acceptable.
Neil Ernst
Member
[1] http://blog.acm.org/president/?p=67
My new gig at UBC
It has been an eventful fall. As I finished my PHD writing in late August, I had two conferences to attend — the Requirements Engineering conference in Italy, and the International Workshop on Principles of Software Evolution in Hungary. Following that, I travelled directly to Vancouver to begin a new position at UBC with Gail Murphy’s group (the Software Practices Lab). I am also responsible for teaching CPSC 310, the third-year software engineering course here.
At the same time, or near enough as makes little difference, my wife gave birth to our second son in Toronto. Since everything went swimmingly, she and the children joined me at our place in Vancouver at the end of October. Needless to say life went from work-oriented to family-and-work-oriented in short order.
So the fall has been a little hectic, as we all get used to the new situation. I have found it challenging to get everything properly scheduled (children have a way of disrupting my careful planning). As with most university instructors who also do research, I have found it hard to balance my teaching responsibilities with my research duties. The most effective thing, so far, is to not even allow oneself to consider teaching tasks for certain periods of time. At any rate, it is taking a little while to transition to a new environment and new research goals.
The key for a post-doctoral fellow is to publish good quality papers to enhance one’s academic CV. Since the positions are typically two to three years long, that means you have at most two or three deadlines per conference to target in your time as a post-doc. That makes it challenging, since (in my experience) each paper is the product of at least one year’s work. You can do the math, but essentially time is of the essence.
Our group here is one focused on the software development task, by and large: how humans write and understand code. This makes it a bit different than what I worked on for my PHD, which ended up fairly theoretical, relying a lot on automated reasoning and formalization. However, the purpose of taking the position at UBC was two-fold. One, I think working with smart people of any persuasion will inevitably rub off on you – you need to work with the best to raise your game. If you aren’t feeling challenged and inferior, at least occasionally, I think you are falling behind. More specifically, my intent was to examine my PHD work in the context of software development.
Research questions
As part of my adjustment period to the new environment, I’ve been reading and thinking at a higher level than I typically get time for. I want to refine where I would like to aim my research career for the next five years. To that end, I’ve been listing some research questions that interest me. I list some below, and intend to post more about them in subsequent weeks. I think my overriding focus is starting to clear up: I’m interested in the intersection of business objectives with the software development process. In particular:
- How do business objectives manifest themselves throughout the software lifecycle?
- How do we reconcile a yearly financial cycle with the different cadences of software projects (or design in general).
- How do developers handle software maintenance?
- What exactly is the theory-building approach to software development?
What I learned at UofT
My dissertation is nearing approval (touch wood) and I have started a new position as a Post-doctoral Research Fellow and lecturer at UBC. I wanted to summarize my experiences in grad school as a reflective exercise. I often found I got down on myself during the process: it is an incredible challenge to acquire a research Ph.D. at one of the top-10 computer science schools in the world. I’m extremely proud of my past selfs for persevering and allowing 2011 Neil to reap the reward, as it were. ‘Cause 2006-2008 Neils put up with a lot of sh*t.
These are all things I knew nothing about when I arrived for my PhD in 2004:
Languages and Tools
- Python (matplotlib, numpy, networkx)
- Lisp (SBCL and Clozure)
- Git and SVN
- Twitter, Facebook, WordPress
- Mendeley
- Latex + Scrivener + MMD3
- Flash / Flex
- Sqlite
- Ruby/RSpec/Rails/Gems
- MDE with Eclipse and GMF
- Logic programming with ATMS
- Knowledge representation
- Propositional logic
- Non-monotonic logic
- Latent Dirichlet Allocation
- Agile software development
- A smattering of Italian (via ferrate means “iron ways”).
- The importance of good coffee.
- How to change a diaper at 4am without turning on the lights.
- Friends: It’s somewhat trite to say that it was the people you met who you will remember, but that’s true. I think one of the most enjoyable things about moving on to a new experience is the idea that there will be all of these people you will call friends in five years, of whom you know nothing now.
- How to prepare and defend a 60,000 word opus starting with no knowledge of the area, no relevant background skills, and little to no published work. In that context seven years seems about right.
Ultra-large-scale systems: fundamentally different?
An emerging trend in software research is a focus on complex software systems. These systems are typically:
- decentralized: a lack of hierarchical control.
- display emergent behaviour: unexpected behaviour arising from unexpected interaction effects.
- subject to network effects: a rich mixture of human and computer agents.
- large-scale: millions of lines of code, thousands of agents.
An example of such a system is the stock market, or the US military’s future soldier program. Two major initiatives have been developed to focus on these systems: the Software Engineering Institute’s ULSS program and the Large-Scale Complex IT Systems (LSCITS) program in the UK. According to these programs, there is a “Software Problem”, and the tools and techniques we use today must be radically improved if they are to manage these new challenges.
But as Peter Norvig illustrates in this article, we have managed to scale from the half-million instruction programs of the 1970s to the hundred-million instruction programs of today. So why do we expect not to handle the billions of instructions in a ULS system? I’m not suggesting we build software perfectly today. There are many improvements possible. But I’m not sure I agree there is some fundamental challenge we cannot currently address.
One thing I think is important is the ability to fail gracefully. One lesson that seems to have been learned over the years (and the idea surfaces from the start in SE) is that iteration is fundamental. That means building systems such that failure is not fatal. Naturally, in some places that isn’t possible (medical devices perhaps). But even in these seemingly obvious examples, it should be possible to fail usefully: to alert someone to the problem, supporting remote software updates, or incorporating more adaptation capability.
The point of this post is to ask whether the statement: “Our ability to develop, maintain and manage such systems is falling behind the growth in their complexity.” has any evidence behind it. Standish reports need not apply.