I consider myself an early mobile adopter. I had Casio PDA, Sharp PDA (the first to sync with the PC), a Psyon, the original Palm, a Nokia communicator. Finannyl I ended with a Blackberry 8707. It did eMail very well, the big keys matched my big hands and live was good. Of course even I fall victim to perceived obsolence. The 8707 showed its age. All the new applications like Quickr, Facebook, Tripit etc. wouldn't run and first and foremost: no wifi and no option to keep the phone running while roaming but switch the data off. So I decided to treat myself to a shiny new Bold2 9700 (mostly since Android hasn't been cleared by IBM security yet, at least not here).

It had all I wished for: applications, camera, memory, wifi, roaming. Others praised it as their parachute. Seems mine has a few burn holes and it will be my last Blackberry unless things improve dramatically very soon.

1. BES jail: I paid for the unit. I foot the monthly bill (and to connect to a Enterprise Server Singapore's mobile provider require the premium plan). Nevertheless I'm not in charge. The configuration settings are hidden in what Blackberry calls "Service books" which only can be issued by the BES admininstrator. Lets say he is trying very hard.
2. Browser confusion: there is the Blackberry browser, the hotspot browser and the Gee browser (the later courtesy of Starhub). Depending on connectivity one or the other works or doesn't work. And they suck all together. The 8707 at least didn't try and resulted in ugly but readable pages. The new browsers try hard and render unreadable small pages. There are only 3 zoom levels and the browser forgets them graciously between pages
3. Network reliability: I don't want to care if I'm in a hotspot or mobile ot inside my firewall. Once I teach a device how things are it should work behind the scenes. The 9700 doesn't. Messages are not sent without explanation. It only tries for a few seconds - sometimes, sometimes it sends and receives within the blink of an eye. Services are not network flexible. Some work on mobile but not wifi (e.g. the Blackberry marketplace), some on wifi but not mobile, some only if only one is on. Behaving like this I don't consider it a trusted device anymore.
4. Keyboard: The 8707 is superior to the 9700, so I expect a further detoriation
5. Buggy software:Incoming and outgoing calls are associated with random numbers. E.g. notification I get from TripIt (a UK SMS) is linked to my aunties German handphone number. I called a cab, the log later says: "Call to cab" but listing my wife's number as destination
6. Desktop software: I use Linux as my day to day OS. For a lot of functions I need a BB desktop client. It is mainly Windows, so I need to keep either a VM with working USB or a separate machine around
7. Not my problem: The phone company tells me it is a BES issue, the BES admin blames the phone company, nobody I can visit and sort things out and the hardware guys (maybe my unit is faulty?) don't understand a thing about networks.

I don't know if I just experience the perfect storm of mishapt, but I'm not surprised that 33% of the Blackberry users want to switch to Android and 40% to an iPhone

Ferris analyst Bob Spurzem covers news around MS-Exchange. In this entry he hightlights that MS Exchange 2010 has removed the Single-Instance-Storage (SIS):
One of the lesser-known changes to Exchange 2010 is the removal of single instance storage (SIS). The reason for this is related to an architectural change, disk I/O performance, and the availability of cheap disk.
There tends to be a trade-off between better disk I/O performance and reduced storage capacity. Architecturally, Exchange 2010 introduces a new per-mailbox table structure that replaces the original per-database table structure. The original per-database table structure was optimized for SIS, but disk I/O suffered. The new per-mailbox table structure improves disk I/O, but without SIS.
In place of SIS, Exchange 2010 uses compression. Only large, redundant attachments files truly benefit from SIS; otherwise, compression delivers roughly the same volume of data as SIS."
Well MS sales people always had claimed (never backed by figures from real deployments) that SIS was a space saving advantage over Domino's one-man-one- vote database approach. Guess they learned the scalability lesson the hard way. Now if you want SIS for attachments and design compression and data compression - Domino is your answer.

The most talked about space saving feature in Domino 8.5 obviously is DAOS. The lesser talked space saver is ODS51. ODS51 features (not neccesarily introduced only then): Design compression, document compression, LZ1 attachment compression. I put it to the test with my very own mailbox (happily running R8.5.x and ODS51):

The same database after creating a copy in ODS43 (R6/R7) format. Nota bene: it doesn't contain any view indexes yet!

If you do the math: 357 -> 197 => 45% reduction in size. I don't store attachments in my mail file. Files that don't directly go to Quickr, LotusLive or Lotus Connections are taken care of by IBM's My Attachments tool effectively moving them to their own database.

Michael Sampson, teamwork expert, points us to an insight from Nicholas Bate about team performance

Of course good presentations help to show off the good work. Until then focus on 7 pillars and clarity.

It is not enough to translate your software into another language.

You also need to teach it how to recognize Re: and Fwd: or you get the above result

Depending on whom you listen to TCO is the lowest for [insert-your-product-of-passion-here] Robert Sutton (a must read, yes - every book ) suggest to base management decisions on solid evidence . So what is part of TCO? Hardware and software prices, real estate in the server room, electricity and cooling, labour for the admin for regular operations, patches and upgrade as well as opportunity cost for downtime. I'd like to shed some light on the hardware side. In a loose series will compare the hardware deployment for various IBM and Microsoft scenarios. For starters I use a comparison of plain Domino with plain Exchange. In a later post I will add mobility, instant messaging, collaboration and whatever comes to my mind. My first scenario is a single location with 12000 heavy mail users who demand high availability. Since I'm not a Microsoft expert I need to poke into public available resources for the deployment diagram and I guess I'll stand corrected in one or the other case. The first thing I had to learn about Exchange is that an Exchange server can have different server roles and that it is considered best practice to split these in large installations. HP's sizing tool for Exchange 2007 was used for the Exchange estimates.

While discussing AutoUser, the top tool to run functional test for your Notes Client applications, with Lucius (Smart Touchan's CEO) we compared Notes (pun intended) about the state of Notes applications. We identified a phaenomenon which Lucius labeled " frozen Notes applications" (Accenture seems to have still quite a lot of them).
A frozen Notes application isn't one that is crashing or mis-behaving. It is one, mostly at the core, supporting a critical business process with tentacles interfaces in all directions. Since it has grown over the years there are quite some layers and imprints of developer generations in it. It typically does what it should do well, but there is great reluctancy to touch it. Its interface shows signs of age and enthropy. Neither adding or altering features nor moving it to a new version is considered a risk worth taking by the IT people (I actually have seen R4.6 servers still in operation for exactly that reason). Updating this application is what Wikipedia calls Brownfield development (a term borrowed from civil engineering).
What to do in such situations? The tempation is great to just rewrite the whole thing on a platform that is more in vouge. Joel Spolsky has warned against such attempts and reports coming in of rewrites (regardless of what platform, just ask about VB to VB.NET rewrites) are not very encouraging. A step by step modernisation looks more tedious in theorie but appears to be way more robust in practice.
So what is the right course of action? Document your apps (watch this space for an upcoming feature about that) and put them into a test harness. Way back there used to be LoadRunner (not sure if it is still around) supporting Notes clients. Now there is AutoUser wich is capable of testing applications against a multitude of clients. Refactor your applications when adding new features. Lucius is musing to make AutoUser more widely available. I'm looking forward to that.

In the beginning there was C:\Notes and C:\Notes\Data and a notes.ini somewhere in the path pointing to the data directory. And live was good. Over time things became more complex powerfull, the notes.ini moved to the data directory (fun when upgrading) to accomodate multi-user installs. Notes 8 arrived and Notes turned into an Eclipse RCP application uniting the classic C core with a flexible UI based on IBM's Expeditor Framework. Now there is a lot more to Notes (my program directory totalling 23768 entries using 958 MB - that's client including Symphony and Sametime on Ubuntu 9.10). While you still can wipe the program directory and reinstall everything, you want to maintain all data that are relevant. In a recent Domino WIKI entry the meaning and purpose of the structure of your data directory is explained in detail. Makes an interesting read.

A mechanical, an electrical, a chemical and a civil engineer fell into an argument what kind of engineer god would be. Using man, the crown of god's creation as an example each of the engineers argued his case. The mechanical engineer explained: " Look at the skeleton, the joints, the spine and the delicate balance it is capable of. God must be a mechanical engineer". "Wait a second" replied the electrical engineer. " Look at the nervous system, the eyes and the brain, that is electrical engineering at its best. God must be an electrical engineer". The chemical engineer stated: " The digestive system, the blood circulation, the liver, the lungs and the intestines are the best of the best in chemical engineering. God must be a chemical engineer". The civil engineer smiled: "You are all wrong. Of course god is a civil engineer". Astonished the other engineers demanded him to explain.

10 years ago the biggest adventure of my life started. It is still on and I'm still learning.

Happy birthday Anthony and Ernest!
Being a geek dad we celebrate with the appropriate present and stuff to chill out afterwards.

Singapore is one of the most wired companies in the world with a Broadband penetration exceeding 100% (Korea take that ). I recently switched to Starhub from SingTel on one of their midrange plans (not the alledged 100 MBPS one), so I was curious and headed over to SpeedTest to check how I'm doing. Locally I got 8.42 Mbps and overseas 5.37 (Boston), 4.76 (San Franscisco) and 5.3 (Texas) Mbps.

Should be ample power for any web based application isn't it? Not so fast. Just recall how most of the web 2.0 applications with their Ajax goodness actually work:

(Image shamelessly borrowed from JustGoodDesign.com
You will realize that while you want all the speed you can get for watching video or download files, you want fast reaction to your requests too. Reaction time in the internet is called latency. How long does it take the other side to react. There are many factors influencing latency. Physical distance, quality of lines, number of nodes to traverse, things happening on that nodes (packet inspections, firewall activities) etc. In a local network you can expect latency in the range of less than a milisecond up to 3-4ms. Once firewalls get inbetween figures get higher. Here the Singapore figures (mesured using ) look different:

Locally I got 31ms (just 15x slower than a 2ms local network), overseas between 200ms and 350ms (just 100x and 150x slower than the lan). You can imagine what that does to your "chatty" web2.0 application. While 100 calls in the lan take just a fifth of a second you would need to wait 20sec on the slow connection. Now travel to places sourrounded with great walls or exotic destinations and your app will suck big time. My recommendation for all web2.0 developers: Schedule some time in a remote development facility (Yes people actually write code there) but leave your servers at home.

The good Movie Bag is loosing shape and SWMBO insists on replacement. SoI had a look at Varier: