- Currently Listening to:
- Phoenix — Too Young
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.
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.

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.
- Marco.org - The Mac App Store isn't for today's Mac developers
- Panic Blog » Panic State of the Union
Last year’s plan for the future of Coda was to keep things simple, not touch the UI, and only focus on highly-requested editor features. Something about that didn’t feel quite right to us, though — it wasn’t a “true” Panic 2.0? — so after two fateful days locked in front of a whiteboard, we’re now looking at more substantial improvements and changes, while trying our best to stay balanced (keeping in mind the supreme court case of Baby v. Bathwater).
- Subtraction.com: Someone Could Make a Lot of Money with Personal Finance Software
Think about it.
- Picking a Ship Date - Joel on Software
So my basic rule for software release cycles is: Set a ship date, which might as well be arbitrary Make a list of features and sort them out by priority Cut low-priority features every time you slip so as to make the date.
- Fixing Venture Capital - Joel on Software
I've drawn these curves moving up at roughly an equal rate. That's not a coincidence. In a small company, you regulate each of these curves so they stay roughly in sync. Why? Because if any two of those curves get out of whack, you have a big problem on your hand—one that can kill your company. For example:
- Marco.org - Why you should consider OS X
Mac software follows design principles that you rarely see in Windows:
Incredible attention to detail
Simple, clean interfaces
Justified, focused feature design (no “kitchen sink” apps)
Respect for the user’s time (no stealing focus, no unnecessary prompting)
Respect for the user’s intelligence (no “we’re protecting you from this choice”)
High quality (if it says it will do this and work this way, it will)
- “Can u suggest me screencasting app for Mac plzzz!” « Smoking Apples
- Funware’s threat to the traditional video game industry | VentureBeat
Call it Funware. That’s the name for applications with game-like mechanics and game-like behavior that really aren’t traditional video games. And Funware just might steal the thunder from video games, which may no longer have a monopoly on either interactivity or fun.
With new places to play — such as the iPhone, on Facebook, or even with Google mash-ups on personlized web sites — web-based social interaction is changing the way that many people entertain themselves.
Funware game mechanics include things like leader boards, tournament challenges, ratings systems, badges for accomplishments, levels, and other things that can boost user engagement. Users find these features enticing because they elevate the user’s status in the eyes of the community.
- The Case for Universal Apps - The iTeleport Blog
We turned out to be right on both counts: making iTeleport for iPhone a Universal app did upset some users, and we believe it will be better for us in the long-term. Obviously, the users that got upset were the ones that bought the iPad-only version, and saw that iPhone users were getting both for free. Or, they bought both the iPad and iPhone versions separately, and were (understandably) angry about having to pay twice for something they could now get for the price of one. We did our best to be open and accommodating to these users, suggesting refunds and even offering promo codes in some cases. Some users understood; some not so much. It was painful for a few weeks, but we’ve gotten through it now. Now, about a month after the launch of the Universal app, we are happy with our decision. Users are very happy to see (and pay for) Universal apps, and there’s less confusion.
- Quality over Quantity: How We Built iTeleport into a Profitable Business on the App Store - The iTeleport Blog
A maximum of almost $2,800, and it never drops below $1,000 a day. The data pretty clearly shows that we've been able to generate significant revenue without driving a high volume.
How did we get here? We believe it's a combination of creating a high quality product with great support in a well-defined market with significant demand. This doesn't sound too different from classic definitions of how to develop a successful software business, and it's not. We've done very little marketing. The app has been featured a couple of times over the past two years, but for short periods and not enough to explain the sustained level of revenues. Word-of-mouth is probably the best explanation of how revenues have sustained themselves. That, combined with offering something people really want, and are willing to pay a premium for if you give them distinctive, useful, hard-to-find features in return. Yes, there are cheaper, or even free, VNC clients. But they either suffer from poor connect