My interest was piqued as these cards have an interesting side effect: Miles do not expire anymore, provided you use one of the credit cards at least once a month. But is it really worth switching credit cards? The starter offer , called “classic” costs 120CHF annually. The next tier cards are Classic Plus at 180CHF, Gold at 300CHF and Platinum at 700CHF annually. With Classic Plus and Gold, you receive a flight voucher for the full annual membership – so your upfront cost is zero, provided you can use the voucher. With the Platinum card, you receive a voucher for 300CHF.

Cost and benefit:

Let’s approach this mathematically. First, we need to figure out some of the things that aren’t so clearly stated on the web site. While we know what the offer costs (120CHF/year or more), and how many miles you get (up to 1.25 miles/2CHF spent with the “classic” offer, up to 1.5/2 CHF, and up to 1 mile/CHF for Platinum), we don’t really know how much a mile is really worth. So, how much is a mile worth?

As it turns out, not all that much: €0.0073 on average, according to a Lufthansa publication from 2008 [source], that’s just about 1 Swiss centime. For the Swiss branch, I could not find comparable information, but took two samples instead: For goods on promotion in the Swiss Airlines store, I arrived at 0.0079CHF/mile. Looking at award air travel, I came to 0.0105CHF/miles (details). Sounds about right, so let’s take this last figure.

So, the math is simple. There are two things we need to compare: The cost of having these cards, and the benefit we’re receiving from them. If benefit minus cost is positive, we’re good. If not, we’re wasting good money.

That means: At the very minimum, you have to spend 16700.00 CHF annually just to break even with the Classic offer. Upper tier cards look a little better, as the ValuePack allows you to reclaim the annual fee in flight vouchers from Swiss.

If you’re flying with Swiss on your personal account, the flight voucher option might make things interesting, at least for the classic plus and gold offers. Not so much for the Platinum card, but then, if you have a platinum card, you probably couldn’t care less.

Here’s a graph of what your bonus will be, given your annual spending and assuming none of it is in foreign currencies:

Variable costs: In reality, things are more complicated! Miles and More credit cards charge a (rather steep) 2.5% service fee for all purchases effected in a currency other than CHF. This variable cost depends on the ratio (r) of foreign purchases contained in v, charged with a service charge (f) of 2.5%. If you’re like me, that ratio is rather high, as you use your credit card mostly abroad and other means of payment at home.

As the 2.5% service fee rapidly eat up your <1% bonus, you have to be careful not to purchase too much in foreign currencies. The limits are as follows:

The amount of foreign purchases allowed depends on your annual volume, but in a non-intuitive way: For the ClassicPlus and Gold cards, the relation is opposite from the Classic and Platinum cards, as the latter always have an annual fee.

Summary: Now, what should I do?

What I am NOT considering in this analysis are soft factors, such as the good feeling holding a platinum card, or the various hard-to-quantify benefits provided by the cards, such as the non-expiry of miles. The ValuePack also offers 5 stays in Swiss Airways lounges at a reduced price, but in my opinion, there are good alternatives to that. I have limited myself here to those benefits that are readily convertible into money.

All things considered, neither the Classic nor the Platinum cards look particularly attractive, as they have fixed, non-redeemable annual costs. The platinum card does accrue bonus miles faster, but that only gets interesting at annual volumes above 140000CHF, so this is definitely for persons with a larger purchase portfolio.

The recipe to make the most of your card then is to take the Gold set, pay as much as they let you with it in Switzerland, but spend the least possible amount in foreign currency. Finally, use the CHF300 voucher for a flight, or else you’re endangering your profits.

What did I learn from this myself? On average, my credit card bills have 51% of foreign currency purchases. With this ratio, none of the M&M cards is attractive for me. I will stick for the time being with my PostFinance MasterCard, which offers 0.5% bonus on all purchases, but only charges 0.9% on foreign currency transactions. On the other hand, I’ll have to be careful to not let my miles expire.

Talk back to me, I am interested in your opinion!

Appendix: Methods

Estimation of value of M&M miles:

Swiss Airlines promo on goods acquired with Miles: 1 mile = 0.0079 CHF. Currently, the Swiss Airlines online shop sells a Deuter backpack for 20′000 miles. The shop states the price of this backpack at CHF 179.-. That’s a little blown up, a price search shows this backpack to have a mean street price of CHF 158.70. Ergo: 1 mile = 0.0079 CHF

Award flight with Swiss: 1 mile = 0.0105CHF. Basis: Flight BSL<>LAX in Y costs 1259CHF excluding taxes and service fees (as priced by Swiss Airlines). The same flight could be obtained as an award using 2 * 60000 miles.

Calculation of break-even point without foreign currency purchases:

The variable we’re observing is the annual total volume of purchases (v).

Benefits: You receive an annual bonus (b) of e.g. 1000 miles for the classic option. You also make 1.25miles/2CHF spent (let’s call this fraction i for “toMiles”). We need to compare money with money, however, that’s where the factor o (for toMoney) comes in.

benefits = o (iv + b)

Fixed costs: The annual fee (c) is a fixed cost. There are variable costs, we come to that in a minute.

cost = c

Now, we can find out how much money we need to spend to break even:

o(iv + b) = c

or: v = c – ob / oi

Model including variable costs:

o (iv + b) = fpv + c

where f: service fee on foreign currency, p: ratio of foreign currency purchases

Maximal allowed ratio of foreign currency:

p = (oi +  (ob – c) / v ) / f

Session Kanban cards at XP Days Benelux 2009

I have attended a fair share of (scientific) conferences, and in my experience, the interesting things always happen in the coffee breaks, or in the poster sessions. Lectures are somewhat stiff, usually scientists talk about work they’ve already published, and it is very rare to hear any truly new insights. Finally, questions after the session are often pro-forma, and rarely lead into deep discussions due to lack of time. Don’t misunderstand me – conferences are important places to meet, but the official program often isn’t too captivating. Go into a lecture hall and watch from the back what all these people with laptops are doing – working, skyping, coding, writing email… but I am getting off track, I think.

At XP Days Benelux, this was all different. People come to share and to interact. From the start with an icebreaker session each morning (and I was still thinking “oh no! psycho-touchy-feely stuff!”…), people started networking, and I have met a lot of interesting people and have had interesting conversations with many, inside sessions and in the coffee breaks. It was a very enjoyable experiences, rounded off with the games night in the bar, where werewolves and belgian beer were the driving forces.

Xavier Quesada and Laurent Morisseau held a session on Visual Management for Agile Teams. Here, we built scrum task boards in groups and discussed the many different ways you can actually do that and what it means for the team and the managers.
The Retrospective Hero session by Nicole Belilos and Willem van den Ende used a role-play simulation that challenged two coaches (and they did warn the audience – don’t be a coach unless you’re experienced) to manage a crisis and lead the team through learning lessons from it. It was scary how well people slid into their roles! One big lesson: In a crisis, try to let the team voice their emotions first, as they will come out anyhow. But (a big but!) do it without going too much into the touchy feely direction.

The action continued into the night with a BoF by Pierluigi Pugliese on his solution focused approach to agile coaching. Another BoF was run by Serge Beaumont on practical tools, like the Ready state and Jeff Patton’s Story Mapping for the Product Owner. Both BoFs have noticeably created a lot of buzz in the community and it seems clear that Pierluigi and Serge have hit a nerve with what they presented. Moreover, I think that there are a number of points that connect the two talks.

In the Solve Conflicts Without Compromise session, which was run by Pascal Van Cauwenberghe and Jef Cumps, the session leaders tried to introduce a model that allows you to (I am simplifying here) figure out in 6 steps that two conflicting goals can – at least very often – be lifted onto a higher level, where all of a sudden their underlying goals are compatible, and it is just a question of carefully assessing all the assumptions that were made concerning the goals. An interesting approach, but at least in the session, none of the (real life) conflicts were really resolved. Then again, solving conflicts in 90′ is a big feat to aim for, if you are doing it for the first time, even more so.

Eating your own dogfood: Using Agile methods to set up conference desk

Finally, Portia Tung introduced us to the retelling of the Wizard of Oz fairytale, and how you can use the yellow brick road as a path in peer coaching. I found this session amazing, since we were in turn describing our problems, coaching others in addressing their problem, or observing the coach-coachee interaction.

But, as I said in the opening paragraphs, the sessions are excellent but aren’t really what makes this gathering great. It is the very open spirit, a genius loci (there really isn’t much more to do around the conference center either), which makes the participants try to learn from each other rather than try to get the daily office work done on their laptop during the sessions. Oops, there I am back with my initial rant – so I better stop right

There was recently not so long ago a discussion at InfoQ, triggered by an opinion piece by Amr Elssamadisy. Michael Hedgpeth suggests that the bad reputation Scrum attributes to “classical” management may backfire in corporate cultures run by people who believe in traditional management. This made me wonder about the management culture and styles that we can observe in academia.

In brief, the argument goes that developers like Scrum, because notions like “chickens and pigs” put the pointy-haired bosses in their place, and give all the power to the team, but that it is this rebellious notion that makes Scrum unpopular with management.

In university, I have observed the complete opposite: It’s not the managers who are uncomfortable with Scrum, but rather the scientists and developers, who feel that their personal liberty is at stake — slightly causticly defined as: “I come in to the office in the morning, and do what I feel like, without feeling committed, and hopefully, great things will result”.

The management hierarchy in university research groups is rather flat, with a PI (principal investigator, group leader), usually a professor, on top and in charge of the project overall plan and finances, and a group of post-doctoral fellows, grad students and undergrads, as well as technicians or programmers, working on subprojects within the overall plan of things.

Apart from this, there is no explicit hierarchy, at least in the majority of groups that I have seen. Still, there is of course implicit hierarchy, based on seniority and in the best cases, on experience and merit, after all, the university is the one place that should reward learning and experience.

As we started implementing Scrum in research groups, we wondered what the best way to distribute the Scrum roles is. The answer, of course, is “it depends on the circumstances”. Still, here’s my current best thinking on this item:

The first question is who owns the project, especially if you are avoiding solo scrum by running a sprint with many several subprojects, as  I described in a previous article. Is the individual scientist the Product Owner? After all, she’s the “single wringable neck”, the one person ultimately responsible for the work being done correctly and timely.

On the other hand, an individual scientist, in particular at the graduate student level, often lacks the seasoned view of the veteran and isn’t able to perceive what avenues are promising, lacking the experience of long years of trial by fire. Here, the group head can contribute his or her experience, and the big picture view of the research subject that results from having been there, done that, and written a couple of reviews about it, as well.

So, we decided that the PI, or group head, should be the product owner in a science scrum project. Not an autocratic PO, but rather someone who listens to valuable input from his constituency, the grad students and post-docs, who might lack the big picture view, but who offer valuable input “from the trenches” nevertheless. The group head must take their input seriously (which should be de rigeur in any scientific endeavor, it goes without saying) but is in charge of planning and keeping the product backlog up-to-date, regardless of whether you’re producing software or writing papers as the end result.

(No funny lead picture about restaurant complaints this time … but a comic. Thanks for staying until the end.)

I found this interesting article this morning. I need to read up on Reed-Solomon codes.

Slashdot had a post up about an essay by Matthew Paul Thomas. You can read it here.

Its point is that while the open source model of software development is able to achieve good code quality by opening up all sources & letting others fix and build on your previous work, the model breaks when it comes to software usability.

A programmer may want to scratch their own itch, and not care so much about presentation and interaction with the program, whereas someone experienced in usability design may lack the necessary coding skills to just take the source and “patch the user interaction”.

In academic software, this is only worse… here, scratching your own itch is the main motivation, and documentation, maintainability and usability more often than not are so way down on the list that they’ll be done “right after I’m through with graduation”, which is never.

Some of these points are also discussed in this article, which goes back to a rant from Eric S. Raymond himself.

Heute Morgen im 34ger-Bus. Ich steige ein, mache gerade noch die Email-Applikation auf meinem iPhone zu, und will es gerade wegstecken.

Mann im Bus: “iPod oder iPhone?”

Ich (perplex): “iPhone.”

Er: “Hier, setz dich neben mich! (rückt zur Seite) Ich hab nämlich auch eins, willst Du’s sehen?”

Nein, wollte ich nicht, ich glaub’s ihm ja gerne. Und sowieso — ich musste gleich wieder aussteigen. Aber das ist ein Beweis dafür, dass der Besitz so eines Gadgets Zugehörigkeitsgefühle vermittelt. Da brachte ich’s gar nicht über’s Herz, zu gestehen, dass meines einen Alurücken hat… und dass ichs schon seit März hab.

… oder so ähnlich.

Seit heute gehören wir nicht mehr zum aus-Amerika-importierenden Backwater, sondern dürfen unsere iPhones ganz normal im Laden kaufen, bei Swisscom und Orange vorerst.

Ich will ja nicht immer nur meckern, aber wenn man schon heftig den Hype um das iPhone 3G mit ganzseitigen Anzeigen mitanfacht, sollte man vielleicht doch ein Scheit oder zwei Brennholz beizeiten auf das Feuer legen. Seit heute, 11. Juli, 2008 mittags ist die Orange-Website nicht mehr erreichbar, nur noch ein generelles “Sorry”.

Aber, aber… irgendwie war das doch vorhersehbar, dass der Webserver heute ein paar Hits mehr als sonst abbekommen wird. Bei Swisscom’s Website ist noch alles, so scheint es zumindest, zum Besten bestellt.

Vielleicht war’s auch nur das Gewitter, das im Moment auf uns runterprasselt? Na egal, jetzt kann ich halt nicht nachschauen, ob das gute Stück überhaupt noch lieferbar ist.

Today, Google announces the open-sourcing of their Protocol Buffers project. From a first glance, it seems to be a high-performance way to exchange deep data structures between different services (it seems Google has a need for that — they claim that their production servers constantly run at full capacity). XML parsing is not performant enough, raw byte streams are bound to break when one of the producers or consumers changes its internal format. Interface description languages have a bad reputation for being overly complex.

Enter Protocol Buffers. The official announcement is on Google’s opensource blog, and the code is released under the Apache License 2.0.

“Protocol Buffers allow you to define simple data structures in a special definition language, then compile them to produce classes to represent those structures in the language of your choice. These classes come complete with heavily-optimized code to parse and serialize your message in an extremely compact format. Best of all, the classes are easy to use: each field has simple “get” and “set” methods, and once you’re ready, serializing the whole thing to – or parsing it from – a byte array or an I/O stream just takes a single method call.”

Sounds interesting, and it could come in really useful in some of our upcoming projects. I’ll give it a try when I get the chance.

My handwriting sucks. That’s why I use a keyboard whenever I need to make sure that what I write down is actually read/write. Still, I am very fond of good design, and of good typefaces.

The man in blue is wondering about the typeface designers themselves: “There’s great power in a typeface, but what’s always interested me more than the typeface is the designer behind it – why did they create the typeface? Where did their inspiration come from? How did they start?

Lately, I’ve been asking just one question, though. Something which has always intrigued me: these people that help us communicate … how do they themselves communicate? If we strip away the monitors, and the printing presses, and the typefaces … how would William Caslon have written on a post-it note?”

So, he wrote to a number of typeface designers and asked for a sample of their handwriting. Inspiring… and comforting: Some of them produce chicken scratches just like me.

The tool is driven by a database on the server end, which somehow tries to reason about the semantic connections in the  document you’re currently writing. This seems to work to some extent – at least the links and images it suggests are somewhat topical. On the other hand, the “latest articles” tab seems somewhat biased by what the net is already hotly discussing. That may be what you want – but often, you may want to write about something new, rather than something everybody’s talking of (currently, my article bar is full of Firefox 3 launch stories).

Does this tool convince me? Tough call. It looks like Zemanta can indeed speed up the production of an article by providing you with easy access to relevant links and images. On the other hand, I kind of like the oddball images that I usually put on top of my texts. Those, I’d never find with Zemanta.