Archive for June, 2006

Monthly Archive

Time management is becoming an increasing concern around the office, with a number of us turning to David Allen’s highly addictive Getting Things Done methodology. Some basic, seemingly-obvious productivity tips I have picked up over the last few weeks:

  • Don’t sit beside Mark.
  • One of the fundamental tenets of GTD is to get everything out of your head and onto a todo-list. For me, that todo list needs to be web-accessible so that entries can be added from wherever you are. I use Basecamp, which is almost exactly what I need. Though I’m sure when I’m procrastinating about something or other in the future I will decide to write my own, better version ;).
  • Rationalise the mailing lists you’re subscribed to. Some of the ones I’m on (like our internal SRG-members list) need to be always-on, but others, like the list for Gallery developers, is now delivered to me at the end of the day as a digest of the day’s discussions. This has saved me a lot of time.
  • Clear your inbox. I’m a big fan of Merlin Mann’s “Inbox Zero” series (and basically his whole site). It warrants re-reading again and again. Using the two-minute rule and systematically whittling your concerns down mail by mail is highly rewarding, and spares you from having to keep your mail client open all day.
  • In terms of email management, I’ve found that a lot of the habits I’d gotten into actually resulted in me spending more time hopelessly wrangling messages. For instance, there is little point in creating a folder for mail from a certain person, or filtering based on words in the subject. I’ve noticed some people in the labs with gigantic hierarchies of nested folders. The time it takes to decide on these partitions, set up filters or manually place mails into these folders, and then maintain that arrangement over time where requirements and priorities are constantly in flux is frightening.

    With the search capabilities of modern email clients, these filtering steps become redundant, as email is much easier to find again by simply dumping them all into a single place and then performing a keyword search on a large folder. There are loads of strategies you could try, but right now I’m trying to minimise the amount of folders I use. The only mail I keep in my inbox are those that I need to reply to, or the ones I’m waiting for a reply on.

  • In a similar vein, I’ve been realising more and more that GMail is remarkably well designed, once you understand how best to use the “archive” button — which unfortunately seems to have passed a lot of people by. Once you’re finished with a mail that doesn’t require any action on your part, just hit “archive” and you don’t have to think about it again unless you need it in future, by which time it’s nestled safely in your “All Mail” view. You can get similar archiving functionality in Thunderbird with an extension.

Joel Spolsky shares an amusing anecdote about his first review by Bill Gates from back when he was program manager of the Excel team. As I learned in a meeting last week, coming along prepared can make all the difference. Also, Bill Gates looks to be pulling an Alfred Nobel and is planning on funneling almost his entire fortune into philanthropic avenues.

Richard Feynman once gave a fine commencement address referred to as “Cargo Cult Science” (named for the anecdote about unfortunately deluded people in the South Pacific building runways out of straw and coconuts in the hope they would attract loaded cargo planes to land, long after the war had ended). In it he argues through example against any sort of fudging of numbers or spoofing of scientific results, pointing to their poisoning the pools of real, honest science. “Science is a way of trying not to fool yourself. The first principle is that you must not fool yourself, and you are the easiest person to fool.”

Video game music: not just kid stuff is one of my favourite papers from a few years back, because it is arguing for something that I have long believed: writing music for devices with limited sound processing capabilities involves a different way of thinking about the composition. To play some sound effects on the NES, you had to momentarily disable the background music’s percussion channel (this channel itself being made up of intermittent bursts of static). I’ve always found it more interesting to design within restrictions (or “engaging constraint”), which I suppose is one of the resons I was attracted to web design all those years ago.

I attended the workshop on Software Engineering Challenges for Ubiquitous Computing (SEUC 2006) in Lancaster, presided over by Gerd Kortuem.

After a somewhat hurried paper submission about using AOP in automotive software, I decided to change tack, so my presentation was about what kind of problems software engineers in the automotive space are facing. Admittedly I wasn’t presenting any answers, but my presentation went well and, being the only presenter discussing automotive systems and autonomics explicitly, I got a number of interesting questions which created a good discussion.

[PPT] Software Considerations for Automotive Pervasive Systems Talk given at SEUC2006, June 1–2, Lancaster UK.

Here’s an excerpt from my talk:

The modern car is a highly sensorial, complex pervasive system, with thousands of sensors and actuators and hundreds of microcontrollers controlling almost all aspects of the car’s operation; from the multimedia & entertainment systems (radio, DVD players) and navigation/mapping software, to communication both to the outside world and also on a more limited scale to other cars nearby on the road.

A spidogram of automotive software split into modules.

Finally, and most importantly, are the car’s safety systems. Most of the impetus for adding so much software to cars is the supposed benefits to driver safety. And when it works, this is great, but we must also recognise that the stakes are higher. There are dangers involved that most pervasive systems don’t have to be concerned with.

System Personalisation

Much of the talk and discussion involved the implications of personalisation in automotive systems. In the future and to an extent even now, you can choose which features you want your car to come shipped with. This is likely to increase in scale over time, so that a car’s base configuration can be permuted in thousands of ways for each buyer. Modules need to be unobtrusively integrated and interoperable.

Layered on top of this is the possibility of a car being modified, upgraded or damaged over time. Cars will have to be able to adapt to whatever components they have installed, and thus, there is a lot of autonomic computing involved.

Questions & Answers

A few brief (paraphrased) questions and answers that I remembered to write down (not guaranteed to be correct!):

Will hardware and software become increasingly decoupled in automotive systems?
This doesn’t seem to be the way it’s going. As far as I can see (and this was backed up at the workshop), the hardware and software systems seem to be getting more tightly coupled if anything.
What is the development process at the car OEMs?
I couldn’t answer this, but someone else stepped in and suggested that a lot of OEM’s in-house teams are actually graviating towards being software-only development houses, with hardware being contracted out to other companies.
Does the drive-by-wire filtering of a user’s input spoil the love of driving?
Not really a research question, but interesting nonetheless. I do wonder how many drivers could honestly say they’d prefer the primal thrill of risky, unrestricted driving over the increased safety and stability benefits of these modern cars.