Quote from Lao-Tse

I just came across this quote from Lao-Tse on Triiibes that is a real keeper:

"A leader is best when people barely know he exists, not so good when people obey and acclaim him, worst when they despise him. But of a good leader, who talks little, when his work is done, his aim fulfilled, they will say, ‘We did this ourselves.’"

Synaptics Touchpad & USB Mouse at the same time

While Touchpad and USB Mouse worked out of the box on my T61 running Ubuntu 8.04, I prefer the synaptics touchpad driver.  Installing it was a breeze, but it stopped my USB Mouse from working.

While there are a lot of fixes are on the internet, it took me a while to get it to work, mainly because my Kernel was too new.  Most fixes suggest to use the "AlwaysCore" Option in the "ServerLayout" section.  Eventually I found this link which suggests to use "SendCoreEvents" instead.  Now my xorg.conf looks like this:

Section "ServerLayout"
    InputDevice    "Touchpad0" "CorePointer"
    InputDevice    "Mouse0" "SendCoreEvents"
Section "InputDevice"
    Option         "SendCoreEvents" "true"
Section "InputDevice"
    Identifier      "Touchpad0"
    Driver          "synaptics"
    Option          "CorePointer"
    Option          "SendCoreEvents" "true"

Book Reviews: Feynman vs. Watson

Recently I read the biography of Richard Feynman, "Surely you’re joking, Mr. Feynman" and just now the biography of James Watson, "Avoid Boring People".  Feynman won the Nobel Prize in Physics 1965 and Watson the Nobel Prize in Physiology or Medicine in 1962.

The Feynman book I can wholeheartedly recommend the Watson-Book not at all!

Feynman starts off a little slow, but the book gets really interesting and shows a man who is truly passionate about physics.  He couldn’t care less about the Nobel price and was even considering to turn it down.  The book is entertaining and shows a man with integrity and passion.

Watson starts off slow and stays slow.  His book almost reads like a telephone book, with far too many names and facts that are irrelevant to the story.  Although I really enjoyed the science parts of the book.  But after the discovery of the double helix (after the first 3rd of the book) it really goes downhill.  Watson starts to complain about not getting enough salary, he says really nasty things about some people, and in generall comes across as petty, self-centered and back-stabbing.

Don’t forget: Summer is book-reading time!

How to charge for social networking websites

A while back I criticized the Xing business model and the fact that the users – the main assets of the networked – are charged a significant fee.  It’s not that I cannot afford it, it’s more about the fact that they need users as much, if not more than the other way around.

I just discovered Ning, which offers users to build social networking sites – for free of course.  BUT you have the option to pay: You can pay to:

  • Remove promotional links
  • Control the ads shown
  • Use your own domain name
  • Increase storage and bandwidth

Whether the model is viable is to be seen – but I consider it more honest towards the users and more robust against competition.

Requirements in Cocktail Recipes

Being able to follow recipes is certainly a good foundation for mixing a decent drink.  Even experienced bartenders follow recipes, although they manage without the measuring cups and they have the recipes in their head.  Why is that?  A recipe is like a blueprint.  But unlike the blueprint for an air traffic control system, almost everybody can read the blueprint for a Martini.  Interestingly, not everybody can read a cooking recipe!  Just ask any freshman to sauté chopped onions, I rest my case.  

But why are recipes for cocktails relatively easy, and those for software so incredibly difficult?  For one, they are of a different nature!  A recipe is more like a system specification or a process description.  It is designed to be used over and over again for producing a desired, repeatable result.  The software is usually built exactly once, and then distributed many times.  Although in practice, the software is modified, fixed and extended, and having an accurate specification can make a big difference.

Recipes are easy, because we can assume common knowledge between the cook and the writer of the recipe.  When James Bond orders a Martini, the bartender understands what’s meant by shaken, and we know what stirring is.  On the other hand, every chef knows how to sauté, but not every teenager who is away from home for the first time does.  We can strive to make our technical specifications better by stating explicitly what skill set we expect the reader to have, and many technical books have a section describing their target audience – a good practice.

Specifications are easy if a good requirements document exists.  Many projects fail because of faulty requirements, as Tom DeMarco beautifully described in his novel "The Deadline", where the leading characters inspects the requirements for a air traffic control system, just to realize that they say nothing in a sophisticated way.  Contrast that with a recipe, where the requirements are simple: "Make me a Martini", "I need to drive, something without alcohol, please".  "Martini" describes what I want, but not how it’s prepared (although 007 begs to differ).  I leave the implementation details to the barkeeper, who decides what glass to use, the proportions of liquor and so forth.  Likewise, if we collect the requirements for a software, we shouldn’t describe the how ("use XML", "must be Oracle"), but the what ("allow secure communication over the Internet", "must allow ODBC access").

But the main reason why the bartender’s job is so much easier is that he doesn’t have to design the product on the spot.  He gets the requirements and simply picks an existing recipe that fits the bill.

Vincenti distinguishes between radical design and normal design.  Building a car today is normal design – we have done it many times before, the driver sits up front (there once were cars with the driver in the back), and so forth.  But in software we often do radical design, and success at best means building something that will function well enough to warrant further development.

Sadly, in software we are typically faced with radical design, no matter how much the vendors promise a world where solutions are assembled like Lego pieces.  So be prepared to put the required effort in for describing, specifying and building your software – it will be worth it.