« Posts under General

Intended Use vs. Real Use

Often, things are invented to solve a particular problem, but then the invention is used for something completely different.

Take Post-it® Notes, for instance. In 1970, Spencer Silver at 3M research laboratories was looking for a very strong adhesive, but what he found was much weaker than what was already available at his company: It stuck to objects, but could easily be lifted off. Years later, a colleague of his, Arthur Fry, digged up Spencer’s weak adhesive — the rest is history.

Another example is the discovery of this blue little pill called Viagra®. Pfizer was looking for medications to treat heart diseases, but the desired effects of the drug were minimal. Instead, male subjects reported completely different effects — again, the rest is history.

In 1991, a team of developers at Sun were working on a new programming language called “Oak” — the goal was to create a language and execution platform for all kinds of embedded electronic devices. They changed the name to “Java” and it has become a big success: You can find it almost everywhere, except — big surprise — in embedded systems.

I would never have guessed how minute Java’s impact on embedded systems was until I read Michael Barr’s recent article, provokingly called “Real men program in C” where he presents survey result showing the usage statistics of various programming languages on embedded systems projects.

The 60-80% dominance of C didn’t surprise me — C is the lingua franca of systems programming: high-level enough to support most system-level programming abstractions, yet low-level enough to give you efficient access to hardware. If it is fine for the Linux kernel (which is around 10 million lines of uncommented source code, SLOC) it should be fine for your MP3 player as well.

Naturally, at least to me, C++ must be way behind C — Barr reports a 25% share. C++ is a powerful but difficult language. It is more or less built on top of C, so it is “backwards-efficient”. Alas, to master it, you need to read at least 10 books by Bjarne Stroustrup, Scott Myers, Herb Sutter et. al. and practice for five years — day and night. But the biggest problem with C++ is that it somehow encourages C++ experts to endlessly tinker with their code, using more and more advanced and difficult language features until nobody else understands the code anymore. (Even days after everything is already working they keep polishing — if people complain that they don’t understand their template meta-programming gibberisch, they turn away in disgust.)

But how come Java is only at 2%? Barr, who mentions Java only in his footnotes (maybe to stress the insignificance of Java even more) has this to say: “The use of Java has never been more than a blip in embedded software development, and peaked during the telecom bubble — in the same year as C++.”

Compared to C++, Java has even more weaknesses when it comes to embedded systems programming. First of all, there is no efficient access to hardware, so Java code is usually confined to upper layers of the system. Second, Java, being an interpreted language, cannot be as fast as compiled native code and JIT (just-in-time) compilation is only feasible on larger systems with enough memory and computational horsepower. As for footprint, it is often claimed that Java code is leaner than native code. Obviously, this is true, as the instruction set of the JVM is more “high-level” than the native instruction set of the target CPU. However, for small systems, the size of the VM and the Java runtime libraries have to be taken into account and this “overhead” will only amortize in larger systems. But two more properties of Java frequently annoy systems programmers: the fact that all memory allocation goes via the heap (i. e. you cannot efficiently pass objects via the stack) and the fact that the ‘byte’ data type is signed, which can be quite a nuisance if you want to work with unsigned 8-bit data (something that happens rather frequently in embedded systems). Finally, if C++ seduces programmers to over-engineer their code by using every obscure feature the language has to offer, Java seduces programmers to over-objectify their code — something that can lead to a lot of inefficiency by itself.

I don’t think that the embedded world is that black and white. I’m convinced that for small systems (up to 20 KSLOC) C is usually the best choice — maybe sprinkled with some assembly language in the device drivers and other performance-critical areas. Medium-sized systems can and large systems definitely will benefit from languages like C++ and Java, but only in upper layers like application/user interface frameworks and internal applications. Java clearly wins if external code (e. g. applets, plug-ins) will be installed after the system has been deployed. In such cases, Java has proven as a reliable, secure and portable framework for dynamically handling applications. For the rest, that is, the “core” or the “kernel” of a larger system, C is usually the best and most efficient choice.

I, Engineer

Swiss Army MouseI could hardly wait for my new Linux PC to arrive. When it finally did, I ripped the cardboard box open, connected everything, pressed the power button and … was utterly disappointed.

I didn’t want an off-the-shelf PC, partly to avoid the usual Microsoft tax (aka. pre-installed Windows Vista) but mostly because I wanted a quiet PC. All the components (including a passively cooled graphics card) were selected with this goal in mind. Still, my PC sounded like a freaking lawn mower.

One option would have been to send everything straight back, but this would have been rather cumbersome; the other to take care of this problem myself.

I used to be a big fan of “McGyver”, hero of the eponymous 1980s action series. “Mac” was a wonderful person: a good-looking, daredevil who avoids conflicts and doesn’t wear firearms; instead he always carries a Swiss Army Knife and duct tape. He knows how to defuse bombs, how to hotwire cars and is able to fix everything with everyday stuff like paper clips. In short, he is a great problem solver, a great hacker and a great role model.

McGyver would not have sent back the PC — he would have taken care of this problem himself. So I opened the case and found out that — even though I had a passively cooled graphics card — there are four fans in my case: a power supply fan, two case fans (one mounted on the front and a larger one mounted on the back) and a CPU fan.

It turned out that the manufacturer saved a couple of bucks by using really cheap fans, so I ordered ultra-silent replacement fans; yet for my taste the CPU fan was still too loud. I measured the current that ran through it and did a quick calculation to find out which resistor I needed to slow it down to 1000 rpm. Alas, I only had two resistors that sustained the amount of current flowing through my fan: one that was too big (which prevented the fan from starting up) and another one that was too small (the fan was still sounding like a lawn mower). I could have ordered the perfect resistor, but this would have meant waiting a couple of days and paying 10 EUR for shipping and handling. The right “hack” was of course to connect them in parallel, which yielded a resistance very close to the one I calculated. After a little bit of soldering I protected the solder joints with heat-shrink tubing and — voila! — I had a decently quiet PC!

Too many programmers I’ve met are not able to cope with everyday situations. Maybe they know how to optimize SQL queries, but they can’t fix a dripping tap. That’s rather unfortunate as this means that such folks are forever dependent on others. On the other hand, I’ve often observed that principles from other fields can be applied to software development as well, for instance, to build better metaphors. Such metaphors play a major role in getting a deeper understanding of software development, which is very useful for explaining software issues to non-technical people. (As an example, I personally like comparing refactoring to gardening: if you don’t constantly take care of your garden by weeding, fertilizing, watering, mowing, it will require a huge investment in time and money later.)

So step out of the computer-nerd zone and rather be a “jack-of-all-trades”; try to be a true engineer, a person who is able to solve all kinds of technical problems with technical/scientific knowledge and creativity — for your own benefit as well as the benefit of the people around you, but also for fun and profit.

[update 2009-10-29: Alert reader Jörg (obviously a true engineer) discovered an embarrassing mistake: if you connect resistors in parallel, the resulting resistor value is of course smaller than the smallest resistor value of any resistor connected, which means that part of my story just doesn't make sense. Damn! I checked whether the resistors in my PC are really connected in parallel -- which they are. I tried hard to recall what the real story was but ultimately gave up. The hack works -- that's what counts in the end, doesn't it? ;-)
-- end update]

On Pragmatic Thinking and Learning (and Cats)

pragmatic catI just finished reading “Pragmatic Thinking and Learning” by Andy Hunt, one of the “Pragmatic Programmers”.

Besides explaining how our brain works and how to acquire knowledge effectively, he tells many interesting stories and gives pragmatic tips that are invaluable for any knowledge worker.

Most likely this book is going to make it on my yet-to-be-published top 10 of books that radically influenced my professional life. Some positions are already allocated. For instance, number one is Steve McConnell’s “Code Complete” because it turned me from a hobbyist programmer into a professional software developer (I hope). Next comes “Peopleware” by Tom DeMarco and Timothy Lister, because it taught me that software development is all about people and only remotely about tools or methodologies. The third place goes to “The Pragmatic Programmer” (here they go again!) for tripling the level of passion I have for programming.

So what is so special about those pragmatic guys?

I guess it is the way they entertain their audience with immediately usable advice — they are very good presenters. I first met them in 2000 at a conference about Java and object-oriented programming (JAOO) in Denmark.
They gave one of the best (correction: the best) presentation I have attended so far — full of wit, full of fun. Nobody knew them at the time (I vividly recall when at the end of the presentation somebody asked “Who are you guys, anyway?”). Regretfully, I missed the opportunity to buy their then brand-new book “The Pragmatic Programmer” and have them sign it on the spot (I learned from my mistake and had Bjarne Stroustrup sign my copy of “The Design and Evolution of C++” the next day).

Not all of what they write or say is truly novel. Frequently, they reuse material and wisdom from others (a very pragmatic habit, indeed) but they always present it in a context that makes me think “Wow!”. Take, for instance, this quote from Mark Twain at the beginning of chapter 7 “Gain Experience” in “Pragmatic Thinking and Learning”:

“We should be careful to get out of an experience only the wisdom that is in it and stop there; lest we be like the cat that sits on a hot stove-lid; he will never sit on a hot stove-lid again—and that is well; but also he will never sit on a cold one anymore.”

Very profound, isn’t it?

Towel Day 2009

Towel Day in Innsbruck, AustriaYesterday was towel day, which is held every year on May 25. It is a commemoration day for Douglas Adams, the brilliant author of “The Hitchhiker’s Guide to the Galaxy”. The idea is that you take your towel everywhere you go, as — according to The Guide — “a towel is about the most massively useful thing an interstellar hitch hiker can have”.

Douglas, who indisputably died too soon, had the idea for the book while lying drunk in a field on a camping-site: “The idea for the title first cropped up, while I was lying drunk in a field in Innsbruck, Austria, in 1971. Not particularly drunk, just the sort of drunk you get when you have a couple of stiff Gössers after not having eaten for two days straight.”

So me and some co-hackers thought it would be a good idea (and a great tribute) to go to Innsbruck on that day and try to find the exact location. Alas, it turns out that the camping-site doesn’t exist anymore — it has been replaced by a nursing home. Here are the exact coordinates, in case you want to go there as well:

    47°16'33.79" N
    11°25'24.61" E

On the train from Munich to Innsbruck I reread a couple of chapters from Douglas’ last book, “Salmon of Doubt”; one of the chapters is a transcript of a fascinating talk he gave in 1998, which is entitled “Is there an artificial god?” (transcript)(mp3).

The reason why I like this talk so much is that Douglas succinctly explains the origins and purposes of religions as well as how technology and scientific progress — he differentiates between “four ages of sand” — shaped our view of the world and religions. Very inspiring words… a must read (hear) for any carbon-based, ape-descendant, bipedal life form.

Tools I Carry

I recently wrote about the most important tools of a software developer. The tools that I mentioned are important to be a successful developer — they are not sufficient to master the other challenges of life.

Being the geek that I am, I carry all sorts of things in my pockets — things I couldn’t live without. Today, I’ll do a headstand and show you what I’ve got.

First of all, there is my swiss army knife. I need it for all kinds of situations: tightening screws, cutting of loose threads on clothing, opening bottles. Last spring we went on a hiking trip and my son got bitten by a tick — I used my knife’s tweezers to pull it out. It’s amazing: once you carry a swiss army knife, all kinds of occasions arise to use it and you wonder how you could have survived so far without it.

But I had to make a trade-off: naturally, I wish to have as many functions on my knife as possible: many screwdrivers of different shapes and sizes, a magnifier, scissors; and it should have a big blade such that its possible to cut off a slice of bread from a big loaf. All of this is available from Victorinox and Wenger (they even have knives that come with LED lights and USB memory). Alas, there is only limited space in my pockets! I certainly don’t want to carry a brick around. After years of experimenting with various models, for me, the Wenger “Evolution 10″ is the best compromise. Always remember: the best knife is the one that you have on you; a 30+ function knife is of no use if it’s left in your cupboard.

I also need to have a pen on me. Not just an ordinary five cent plastic giveaway pen that might leak ink or run dry. Typically, those pens are also too big to carry them in your pants pockets (I rarely wear shirts, so all my tools need to be placed in my pants pockets). I prefer the famous Fisher ‘Bullet’ Space Pen. This pen is just so cool, so small, so sleek, so robust, so timeless. It comes with a special pressurized ink cartridge that allows you to even write up-side-down — on wet paper, if necessary.

Speaking of paper: a pen — even a Fisher Space Pen — is of little use without paper (unless you are willing to write on your palm or the back of your hand, something I do only in extreme situations). I’m a big fan of Moleskine notebooks and I would love to have one available everywhere I am. Unfortunately, even the small version is too big and heavy to carry in a shirt or pants pocket. By contrast, my ‘emergency notebook’ is quite lightweight: a folded A6 index card, which gives me four pages of about 10 cm x 7.5 cm. It’s not much — but it is something!

Whether there is something to fix or an idea to be jotted down, with my tools I can rise to the occasion; I wouldn’t even think about leaving my house without them.

Reply To All

It simply had to happen again: an unfortunate coworker responded to a department Christmas party invitation, but instead of selecting “Reply” he accidentally chose “Reply to All”. Now 200 people not only know that he will join but also what particular meal he prefers.

Not a big deal, you think?

Years ago, I was on a team facing schedule problems. Our team lead sent an email to our sales manager trying to explain the technical difficulties that we were facing; the whole development and sales team was on the “CC” list. One of the developers replied to the team lead, indicating that a person like our sales manager would never understand our technical problems.

Well, he didn’t use the exact same words that I just used; in fact, he used quite different, actually, rather — ahem — colorful words to express his feelings about the technical abilities of our sales manager. And — you guessed it — he inadvertently clicked on “Reply to All”.

In my view, the one who really is to blame when something happens like this is the company that develops such bad user interfaces. Actually, I don’t know a single mail client that has some level of protection against such embarrassing scenarios.

Here is my solution: When the user selects “Reply To All” change the color of the background to red (or make a beep or some other noticeable change to the look and feel); most importantly, replace the text of the “Send” button with “Send to All”.

The Three Most Important Tools of a Software Developer

What are the most important tools of a software developer? In my view, the keyboard, a programmer’s editor and a scripting language are the top candidates. Compared to fancy design tools they might look mundane – but only at first sight: combined and mastered, they have the potential for making a developer an order of magnitude more efficient.

KEYBOARD

Let’s face it: as a software developer, you spend most of your time writing. Not just code but also test scripts, documentation and email. Hence, the keyboard is your most important basic tool, just like the saw is the most important basic tool of a carpenter.

It is a sad fact that many programmers don’t master touch typing and instead use the “Hunt and Peck” approach: they awkwardly enter text through slow and error-prone two-fingered typing.

The main problem with two-fingered typing is that since it is so cumbersome and slow, developers tend to avoid writing: they won’t write the Perl prototype of an application that would be so useful for the next trade fair and they certainly won’t write comprehensive documentation. Today, a large part of the communication in software projects happens through email, especially if the team is distributed over the globe – what a pity if you cannot type efficiently!

If you cannot touch-type as a programmer, you simply have to learn it. Now.

Fortunately, it’s rather easy. Within a couple of weeks you can achieve marvelous results by just practicing 20 minutes a day. There are countless programs for self-study out there, many of which are free, like KDE’s KTouch. Just do a search on your favorite search engine for “touch typing”. There are even games, like typespeed that you can use to improve your typing skills. Try it out, it’s great fun! However, it is important that you finish a systematic course first; that is, you know the positions of the basic keys blindfolded.

Once you are sufficiently proficient with the basic keys, you should tackle the remaining special keys as well, since they are quite important for software developers: punctuation marks, the ‘at’ sign, braces and brackets. Don’t stop until you know your keyboard inside out. If you catch yourself peeking at the keyboard too often, consider buying a keyboard with blank keys, like DAS Keyboard: a piano player doesn’t need letters on her keyboard and neither do you.

PROGRAMMER’S EDITOR

For years I had used various editors and IDEs for my daily work: for Java development, I used Eclipse, for C++ development Visual Studio, for batch file and test development as well as log file viewing and editing UltraEdit and TextPad; I used Outlook and Lotus Notes for composing emails and usually Microsoft Word for any other kind of documentation. Even though I read the Pragmatic Programmer’s advise “Use a single editor well”, I didn’t know how to live by it – until a colleague gave me a nice tour of the VIM editor about three years ago.

Ever since that day, my developer life has changed profoundly. Now, I use VIM for at least 90% of my writings. I even use it for composing emails, provided I expect my email to be longer than three lines of text. It’s just sooo cool! Now more do I use IDEs for building my projects; instead, I build from withing VIM by invoking a command-line build script; VIM’s “quickfix” feature lets me easily navigate between compiler warnings and errors. For me, the only legitimate use of an IDE is when doing source-level debugging; for changing the code and compiling I switch back to VIM.

I’m not trying to convince you to to learn VIM, since it is a large investment. It took me a couple of month to get some proficiency and even after three years, I’m still learning. But what a worthwhile investment it is for me!

Whatever editor you chose as your single editor, make sure you know it inside-out. Always ask “is there a smarter, more efficient way to accomplish what I want?” and check with the documentation. For instance, you should know how to program it, know how to create abbreviations and shortcuts, know how to record macros. Find out how to run external tools (like executing makefiles or checking out code from version control). Most importantly, learn all the hotkeys and key combinations for tasks that occur frequently, like deleting the word under the cursor (in VIM type ‘daw’) or indent the current paragraph (in VIM type ‘>ip’).

A programmer’s editor corresponds to a carpenter’s workbench: It serves as an integration platform for all your work.

SCRIPTING LANGUAGE

Even a craftsman sometimes needs power-tools to save time and get mundane and repetitive jobs done; so does the programmer and that’s where scripting languages excel.

By scripting languages I mean dynamic languages like Perl, Python or Ruby that don’t use static type checking like traditional languages such as C and Java do. Scripting languages are highly expressive and have constructs that let you achieve miracles in just a few lines of code. As an example, this Perl code

foreach (qx/my_prog.exe/) {
    ++$errors if (/\\berror:\\b/);
}

executes “my_prog.exe”, captures its output and counts the total number of error messages. If you are like me and think that this is still too long, here is the one-line version:

$errors = grep /\\berror:\\b/, qx/my_prog.exe/;

Try this in a traditional programming language of your choice and compare the total number of characters typed – expect that it will be 10 to 20 times as as many.

Most of the time, you will use scripting languages for automation and text processing; however, you can also use it to sketch and smear in order to develop prototypes that you might later recode in a traditional programming language.

A mastered scripting language is a great time-saver: It enables you to write lots of little utilities that make your and your colleagues life easier.

CONCLUSION

The combined power of touch-typing, a programmer’s editor and a scripting language makes a software developer much more productive in two respects: first, it ensures that jobs get done in little time and second, it encourages programmers to try out ideas. The latter is the basis for long-term developer motivation and outstanding performance.

Douglas Adam’s Cookies

I recently read a funny story by Douglas Adams called “Cookies“.

Here is a summary.

Douglas arrives early for a train, and buys a cup of coffee, a newspaper and a packet of cookies. He takes a seat at a table, opposite of a businessman. After a while, the guy leans forward grabs the packet of cookies, tears it open and eats one. In his story, Douglas explains how he – as an Englishman – is not at all able to cope with this situation, so he just takes a cookie himself. A minute later, the guy takes another cookie and so does Adams. This procedure repeats until the packet is empty. Finally, the guy leaves – they both exchange “meaningful looks”. When the train arrives, Adams gets up, takes his newspaper and discovers underneath it – his packet of cookies! Douglas ends the story by saying that “The thing I like particularly about this story is the sensation that somewhere in England there has been wandering around for the last quarter-century a perfectly ordinary guy who’s had the same exact story, only he doesn’t have the punch line.”

A very funny story, indeed…

After my giggling had settled, I couldn’t stop pondering about it. Doesn’t this seemingly improbable story happen all the time, only slightly differently? How often do we think somebody is plain wrong or is unfair to us, when in fact it is exactly the other way around? How often do engineers, salespeople and managers talk at cross purposes? Isn’t this a terrible good example of a paradigm shift, a total change in one’s perspective?

Douglas picked up the newspaper, which triggered the paradigm shift. If he hadn’t picked up the newspaper, he would have walked around for the rest of his life believing that the other guy was pretty weird. So what is the lesson to be learned? Whenever we think we are treated badly or others are plain wrong, we should try hard to find the newspaper — and pick it up.

About me

Hi, I’m your host, Ralf Holly. I’m a passionate software developer living in Munich, Germany.

With this blog, I want to share my views with you on Code, People and … pretty much Everything!
Drop me a line at ralf.holly_at_approxion.com.

ralf_small3.jpg