Semantic Werks

Thoughts on people, machines and systems.

My new gig at UBC

with 3 comments

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?
If you are likewise interested in these questions, (or better yet, have already solved them), let’s collaborate! Please get in touch.

Written by Neil

2011 November 15 at 12:41

Posted in Uncategorized

3 Responses

Subscribe to comments with RSS.

  1. Although I am more in the practical than the research, I am interested in the last two topics you presented.

    The maintenance one mainly because I work on mainline development, but often assist the maintenance team on maintenance branches, and if they are all on vacation, sometimes get pulled in to fix maintenance branches.

    The last one I find interesting as that’s exactly how I program: I theorize and build everything in my head – software takes a physical form in my head with mechanical parts and everything – and then I go about implementing what I built in my head. It’s also how I debug bugs.

    Paul Gvildys

    2011 November 15 at 18:06

  2. Do you find it difficult to context-switch from maintenance to mainline? Or is the code similar enough?

    Neil

    2011 November 15 at 22:58

    • The code is similar enough for the most part (I’m on enough maintenance release code reviews that this holds true for the most part).

      The difficult thing is not just the switching, it’s the “being pulled away from mainline dev” and so having a hard time getting the mainline dev stuff done.

      There’s also the case where some maintenance is so old that it runs on different platforms, resulting in having several Virtualized OSes lying about.

      Paul Gvildys

      2011 November 16 at 07:58


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 384 other followers