My Not So Private Tech Life

Achim, a friend of mine, tells a funny story about his experience with Deutsche Post and its standardized processes and procedures. Deutsch Post World Net claims to be the world's leading logistics group so I guess that by and large what they do works in a reasonably efficient way. However, the bigger a company the more likely you will find it enforces useless or even dysfunctional processes and workflows.

One thing that strikes me is that, nevertheless, many smaller companies try to make a profit by imitating the giants. I liked what I recently picked up in a podcast:

Large companies are successful not because but despite their size. Trying to be successful by becoming large is like trying to become an opera singer by growing fat.

I haven't managed to find the quote's original source. It MIGHT be Peter Coffee's keynote of the Agile 2006 Conference - but I'm not sure. Listening to what he has to say is worthwhile at any rate.

I finally managed to put all twelve articles from my infamous series "Jenseits des Tellerrands" in the German Java Magazin online (as PDF files). It's a collection of articles written by diverse authors all of which try to enlighten the readers on things you wouldn't expect in a magazine focused on Java programming. A couple of the papers break the classical form of technical writing and engage other style of prose: detective story, supervision, conference call protocol, plagiarism of an existing novel and more...

For those of you who do not understand written German, "Jenseits des Tellerrands" means something like "Outside your own plate of soup".

The right amount of configurability in software has always bothered me. Most of the time when using off-the-shelf software I've wished for LESS options to choose from, for BETTER DEFAULT configurations and for UNDERSTANDABLE DOCUMENTATION of the product's configurability. Most of the time when using programming libraries and frameworks I've wished for a special hook to extend or change a certain facet of the lib's behaviour that didn't fit my needs.

In the first case I've often decided to not use a product anymore, judging it too complex for my simple purposes. In the latter case, however, I almost always found a way around a missing extensibility hook - provided the library was doing a good job in the first place. So I personally prefer to have less configurational flexibility or - even better - to have all the flexibility you can think of but it's being hidden from me unless I really need it. A library that requires me to change properties in a few-hundred-line XML file before it can do even the simplest things is useless to my plain and already overloaded mind. Since I'm not the only one who thinks so, tools like Ruby on Rails and its countless clones (e.g. Grails) are spreading and flourishing. One of the fundamentals behind those tools is convention over configuration which is supposed to make standard usage as easy as possible - and in many cases really lives up to this promise.

The trigger to write this entry did not come from software, though. It was the electric lighting in the gym where I play basketball occasionally. During summer holidays all lights, from gym over changing rooms to lavatories, have been connected to an intelligent and allegedly power-saving central control system which is supposed to switch lights off if - and only if - a room is not being used. Installing all those motion detectors and control units was certainly no minor investement. That's what happened when we were playing basketball - well, trying to play:

• We used the one and only light switch in the gym to bring up the overheads - bright and shining.
• Immediately brightness slowly went down to approach complete darkness within three minutes.
• Sometimes a motion detector decided to relight the lights after a few seconds; sometimes one of us had to use the switch again to start over.

Of course, we contacted the janitor at once only to learn that "he didn't know YET how to configure the system correctly". He did try for two weeks, supported by the responsible technicians, only to achieve a slightly better situation: The lights didn't go out any more - if we ran around sufficiently - but they were hardly bright enough to see from one end of the hall to the other. And yes, one problem couldn't be tackled at all: The missing motion detectors at the urinals offered you the challenge of a dark piss within 10 seconds after entering the room.

Yesterday. Competition day. Surprise. All lights on and bright. What I found out is that the janitor has discovered the one configuration option he's sufficiently comfortable with: Switching light control from AUTOMATIC to MANUAL.

I hope you could spot the teachings hidden in this involved story:

Getting configurability right is difficult but important for user acceptance.

Less is more (most of the time).

Have reasonable configuration defaults.

There might be more than one type of target audience for your configuration features.