The Irresistible Force and the Unmovable Object

Decades ago I remember seeing a print cartoon in which a distinguished scientist of Einsteinian sensabilities was deriving a hugely complex equation on a blackboard. From top to bottom of the blackboard the equation got simpler and simpler until it was finally reduced to Time = Money.

Einstein discovered that the two most basic things in the Universe, matter and energy, were equivalent. But in all human endeavors, it doesn't take much experience to develop the gut feeling that time and money are the only things that really matter, and that they are in some way also equivalent.

It is no different in the realm of software development, where time is the prime force and money is the fundamental particle from which all other things, good and bad, flow. Most managers realize this, although they (and I) prefer to think in terms of not time, but time to market (TTM), and not money, but cost of goods sold (COGS). Software developers should think in these terms too.

TTM is the time it takes a product to go from inception to its first (typically beta) customer. All other things being equal (hint: they never are), shorter is better. COGS is the sum of all the costs that can be directly attributed to the production of a product, including both the materials and the labor that go into its manufacture. Again, all other things being equal, smaller is better.

There are lots of good reasons why making TTM as short as possible is important. Having a shorter TTM than your competitors lets you introduce products leveraging new technology before they do. This may give you an advantage in market share. It may let you establish de facto standards in the market which can force your competitors into playing catchup. None of the rationales for shortening TTM are a sure thing, but they are typical.

But there is a more subtle reason for a short TTM. In Lies, Damn Lies, and Net Present Value, I talked about how when you are seeking funding for the development of a new product from your funding agency, whether that agency is upper management, venture capitalists, or the Department of Defense, you are competing with all the other uses to which that funding may be applied. Unfortunately, you are not just competing with other proposed product developments, but with compound interest.

If your funding source merely places your proposed funding in some investment vehicle for the same duration as your proposed TTM, their money grows much faster than linearly. The longer it stays invested, the faster it grows. And all the really big growth in terms of absolute value is biased towards the end of the investment period. What this means is that extending your development period (and hence, your TTM) by even a little bit can have a huge impact on the potential value of your product in the marketplace when compared to just having put the same money in the stock market. This is referred to as the cost of money (COM).

Doubling your development time doesn't double the cost of your project, at least not in the eyes of your investors. It's more like an order of magnitude because of the COM. TTM is an strong force in all product development. But because of the uncertainties that frequently occur when developing bleeding edge products using new and perhaps unproven technologies, it is an irresistible force in that arena.

If TTM is the irresistible force, COGS is the unmovable object. If your product does not cost less to produce than you can make from selling it, then you are obviously not going to make any money selling that product. You've heard the old joke: "How do we do it? Volume." COGS is what this joke is talking about.

COGS is not nearly that simple. A strategy used by many manufacturers is to sell a product as a loss leader, that is, for less than its cost to manufacture, in order to acquire market share, with the intent to raise the price after a bunch of customers are locked in. If you are selling a commodity, that is, a product which can be easily replaced with an equivalent competing product, this obviously won't work, because there is no lock in. But in high-tech, it is not unusual for products to be sold at a steep discount, or, as in the open source world, even given away for free, where money can be made through collateral products, such as service contracts.

(We may pause here to note that in some markets or some countries, there are actually laws against selling products for less than their cost to manufacture. So your mileage may vary.)

COGS has its own special subtlety when it comes to software development. Many managers (and developers) see COGS are purely the up-front cost of developing a software product. The cost of physically manufacturing a software product once it has been developed is nearly zero. It is the cost of replicating and shipping CDROMs, or of running a web server from which the software is downloaded.

This leads TTM and COGS to interact is a manner that may seem fairly obvious. Adding more developers to a project would appear to increase its COGS in more or less in a linear fashion, but reducing TTM can decrease its COGS in a much greater than linear fashion, thanks to the COM. So adding developers to a project seems like a good deal.

Most developers instinctively know that there is a flaw in that argument, just as we all know that three women cannot produce a baby in three months. In the classic software engineering text The Mythical Man Month, author Fred Brooks notes that adding people to a late project makes it later. There are a couple of reasons for this.

First, adding people to a project does not achieve a linear improvement in your schedule. Each added person will cost some time from the existing staff as they have to answer questions and train the new person. Most companies I've worked for have some rule of thumb for the net cost of bringing a new person up to speed. I've seen values ranging from two months to two years used, the latter being for working in an eight-million line legacy code base. The real cost depends greatly on both the developer and the project. My experience is that developers which have a lot of experience recognizing common design and architectural patterns come up to speed a lot faster since they tend to effectively and automatically abstract away a lot of the unnecessary details, while inexperienced developers worry about every gory little thing.

Second, there is a communications overhead as all members of the development group have to coordinate with each other. Software development is, contrary to its mythology, an extremely collaborative activity. This communications cost increases non-linearly. In the worst case, where all developers have to coordinate with one another, as a rule of thumb the interpersonal communications overhead is proportional to the square of the number of the developers.

So merely adding developers to a project to decrease TTM isn't generally the answer.

There is another, largely ignored, aspect to COGS. In The Total Cost of Code Ownership, I talked about how at least 67% of the total life-cycle cost of a successful software product is spent on maintenance. Maintenance is changing existing code: to fix bugs, to add new features or otherwise improve the product, or to adopt to changes outside of the software product itself. The original development of the product accounts for at most a third of its total life-cycle cost. (Other studies place the maintenance portion of the budget at 70% or even 90%. I suspect this depends on the longevity of the software product.)

This means if you somehow magically reduce TTM to zero, you have at best only reduced your total cost of code ownership, which for a software product is effectively your COGS, by a third.

Why is this fact unappreciated? Lots of reasons, mostly tied to (big surprise) money. Market or product managers get compensated for bringing a successful new product to market. Developers are compensated for developing exciting new products. Neither are given raises, promotions, or bonuses for keeping a legacy product working. Maintenance of legacy products is frequently an activity done in the margins. And even if it isn't, that activity is often done by a group separate from the original developers, with a name like sustaining development or current engineering, whose funding comes from a different business unit, silo, or cost center.

This is all a little ironic since for many companies, it is the successful legacy product that is generating most of the revenue that funds the development of new products. I recall once being forbidden by a department head from consulting on a complex legacy product for which I was one of the original developers, despite the fact that the issue with the product was impacting high profile customers. Not his silo, hence not his problem.

It gets uglier. Every developer has worked on projects in which in an effort to reduce TTM, they were encouraged to cut corners. I remember a systems engineer once saying in a meeting "I don't think we have time in the schedule for doing unit tests." (To our credit, the development team ignored him.) But cutting corners leads to what embedded pundit Jack Ganssle refers to as technical debt: it's a debt you take on to reduce TTM, but one which you must eventually pay back. Why? Because technical debt increases the cost of maintaining your product, and hence increases your COGS. Put enough quick and dirty hacks in your software product, and eventually your COGS rises enough that you can no longer sell your product at a profit.

The fact that you may not be keeping a good accounting of the COGS of your product, because its maintenance was moved into a different silo, may lead this issue to bite you unexpectedly. Moving a cost into an area into which it cannot be accounted for does not mean the cost goes away. (I have seen this principle at work when companies do away with desktop PC support, placing the burden of keeping the infrastructure running on the shoulders of their developers. The cost didn't go away. It just got moved into an area from which it could not be accounted for.)

Are there ways to reduce both TTM and COGS? That would be the holy grail. Anything which allows you to generate maintainable code faster would do so. Using languages and design patterns that admit easy refactoring, and using IDEs and other tools that support the same, are a step in the right direction. Software reuse has been seen largely as a failed policy, mostly I think for political reasons. Yet, the C Standard Library is probably the most reused piece of software in the world. As I like to say: "Nobody rewrites printf." The wealth of frameworks and libraries available for Java is a hopeful sign too, but there are so many of them, and they are so complex, that they can bring their own TTM and COGS problems to the table. Witness Fun Facts to Known and Tell: Java Business Integration.

Still, anything that allows you to work at a higher level of abstraction has the potential to reduce both TTM and COGS. Higher-level languages: moving from assembler to C to to C++ to Java to domain specific languages like Ruby. Objected-oriented design: moving from C to C++ or Java, or at least using OO designs in C code. Operating systems with more capabilities: moving from your favorite tiny RTOS to Linux. Reusable libraries or frameworks: C standard library, C++ Standard Template Library (STL), any of the many invaluable frameworks in Java. Using tools that automate or at least simplify the development process: Eclipse for C, C++ or Java, or any of the many great Java tools like Cobertura and JUnit.

When I plan, architect, design, and implement software products, or when I am evaluating new tools, lowering both TTM and COGS is always on the forefront of my mind. In If Java is the new COBOL, is C++ the new assembly? I argued on both a TTM and COGS basis for broader use of both Java and C++ in embedded applications.

In my three decade plus experience, I have seen a lot of effort is spent on reducing TTM. But when it comes to reducing COGS, only the hardware guys get any of the glory. Software COGS is largely ignored. To effectively reduce software COGS, you have to make software easy to modify and maintain.

Asterisk, WiFi, and a Nokia N800 Internet Tablet

In A Future Without Keyboards I mentioned that I had just started to toy around with a Nokia N800 Internet Tablet. This is a pocket-sized Linux system that is less a product than it is an open source platform, which means it's a developer's fantasy.

The device includes all sorts of cool hardware, including a high resolution color touch-sensitive LCD display, WiFi and BlueTooth connectivity, USB and microphone/stereo headphone jacks, a built-in microphone and stereo speakers, an aimable CCD camera, an FM tuner, and two SD-compatible flash card slots. The base software includes a very usable web browser, an email client, a camera, an FM radio, and an Internet radio. I recently added a BlueTooth keyboard. Other accessories I may try in the future include a navigation kit that gives the unit GPS capabilities.



In Asterisk, WiFi, HomePlug, and an Avaya SIP Phone, I talked about the Asterisk PBX in the secure underground Digital Aggregates Corporation computer center (it's a Dell PC in the basement). I've successfully used a number of SIP endpoints with the PBX, including an Avaya 4610SW SIP hardphone and several PC-based SIP softphones. I've wanted a mobile WiFi SIP phone to use around the house and office but I wasn't terribly impressed with either the price or the quality of any of commercial options.

I recently installed the third-party (and quite experimental) Internet Communications Software Update for the N800 from Maemo which includes a SIP stack. It extends the existing internet capabilities of the N800 to include a SIP softphone. So far, initial testing has achieved an occasional two-way talk path. Debugging continues, and it's entirely possible that this is pilot error on my part. Still, I am much encouraged by the prospect of a pocket sized universal internet appliance, something I've sought ever since I used my first Palm PDA years ago.

In If Java is the new Cobol, is C++ the new assembly? I talked about how I thought Java was really underutilized in the U.S. as compared to Europe and Japan in using it as a platform for embedded applications. I made an economic argument based on cost of goods sold, not because Java is the hip thing to be using. (I'm told by those in the know that Ruby On Rails is the hip thing to be using.)

I'm using this little project as an excuse to play with Java Micro Edition (ME) in the Connected Device Configuration (CDC) by installing the C Virtual Machine (CVM) package for the N800 from the open source PhoneMe project. About all I've done so far is get the provided test suite to run successfully, and learn that you can't run applications on the N800 from the SD flash card. Still, it's a step in the right direction.

Hand-held networked universal appliances have been a staple in science fiction. I think they're near to becoming a commercial reality today. Mobile phones are close. Devices like the N800 are closer.

All Things Are Temporary

As if I needed any more evidence that life is too short, I was provided with some on Sunday, July 22nd, that I would have much preferred to do without. My old friend, occasional colleague, and frequent shooting buddy Paul Hyder died that morning after suffering the second of two strokes in the span of a little over a week. I had just sent him a get-well card, and was idly wondering when I could get him back out on the shooting range, and what help I might be able to give him, when his wife Marti notified many of us of his passing. Paul was barely 56.

Paul and I had worked together as engineers as the National Center for Atmospheric Research in Boulder Colorado over ten years ago and discovered that we had many shared interests: technology, science fiction, firearms, and a warped sense of humor. Mrs. Overclock (a.k.a. Dr. Overclock, Medicine Woman) and I were happy to be frequent recipients of he and his wife's gracious hospitality at their mountain home in Evergreen, where we enjoyed the company of their eclectic group of friends. We liked going out to dinner with Paul and Marti, and I for one always took advantage of his interest in gourmet food and wine. Paul was my go-to guy for tips on great new restaurants.

Paul and I were both members of a private outdoor shooting range in the foothills, where several times a year we would meet for a morning of shooting or to take a tactical class together. We did all the usual guy things: blowed stuff up real good, did tactical drills together, discussed who had the cooler firearm (I did), who was the better shot (he was), and just generally enjoyed each other's company while being outdoors in the great state of Colorado. Our interest in this past-time was such that I vividly remember us going one day in the dead of winter when it was so cold, we could only shoot a few rounds before retiring to his truck to defrost. Common sense finally prevailed and we beat a tactical retreat to the nearest good restaurant.

It will take some time for me to get used to the idea of life without Paul Hyder: his quirky personality, his mountain-man appearance, his sense of humor, his deep technical knowledge of networking, and his Glock 10mm. When my mom died in 2006, I am a little ashamed to admit that in the weeks and months afterwards, I found myself thinking about her more than I did when she was alive. When my friend and colleague Mark Uris died just a few months ago (also at age 56), I found it to be true again. I'm sure it will be the same for Paul.

We should never take our family and friends for granted. All things are temporary.

One Hundred Books

I've been accused of making good use of back of the envelope calculations, so called because they are historically done on the back of scrap paper like an old envelope. I'm a big proponent of these simple calculations, which often take the form of a kind of thought experiment. They can sometimes change your entire perspective on whatever problem is at hand.

Computer scientist Jon Bentley wrote a column called Programming Pearls for the journal Communications of the ACM, the articles of which were later collected into a book by the same name. He devoted a chapter to back of the envelope calculations. He discussed how to use simple arithmetical techniques to do things like estimate answers to complex questions, do performance estimates, and compute safety factors. Some of the tips he gives for back of the envelope calculations are two answers are better than one (if you arrive at similar answers by following two different paths, you are more likely to be in the ballpark), quick checks (be sure that the magnitude of your answer makes sense in the real world), and (quoting Albert Einstein) everything should be made as simple as possible, but no simpler.

I recently did a simple back of the envelope calculation to do a little self-discovery, and the result surprised me.

Mrs. Overclock (a.k.a. Dr. Overclock, Medicine Woman) and I share a lot of the same tastes in books. We met thirty years ago as college students in a science fiction club. But our literary interests diverge when it comes to fantasy. Yes, I enjoyed Tolkein's Lord of the Rings. Susanna Clarke's Hugo-winning Jonathan Strange & Mr Norrell was probably the best fiction book I read last year. But Mrs. Overclock finds it irritating (to say the least) when I say that when it comes to whatever latest epic fantasy she's reading, life is too short. My friend Tamarra Noirot, who is also an avid science fiction and fantasy reader, says that I am just not sophisticated enough to appreciate a good alternate history fantasy dragon story. She's undoubtedly right.

But to put things in perspective, let's do a back of the envelope calculation.

I am fifty-one years old. I have maybe twenty more productive reading years left in me. Could be more, but it's not likely to be decades more. Could be less, particularly if I keep pursuing hobbies of potential lethality. But twenty years is a good upper bound. And choosing the number twenty, rather than twenty-one or nineteen, makes the math easy and will yield an answer that is close enough. Doing something like trying to calculate my expected longevity using actuarial tables is way too much work and definitely not in the spirit of the back of the envelope, not to mention completely unnecessary.

I read a lot. In a year, I read about twenty books. Some years more, some years less. Of course, I read a lot more than just those twenty books. I read most of BusinessWeek and Newsweek every week, and just about all of Esquire, Wired, and Dr. Dobbs every month. I also read the occasional motorcycle and shooting magazine, as well as perusing IEEE technical journals, white papers, the occasional article in Harvard Business Review, and a slew of blogs I subscribe to via Google Reader. Can't miss any of Stuff On My Cat. But twenty books a year is in the ballpark.

Twenty years times twenty books a year yields four hundred books.

Of those four hundred books, about half will be fiction. The other half are non-fiction books like Freakonomics, Blink, The World Is Flat, or Peopleware. That leaves two hundred fiction books.

Of those two hundred fiction books, about half will be speculative fiction. The other half are other genres like mainstream or detective novels. I'm partial to Robert B. Parker, but I also read bestsellers like, recently, Special Topics in Calamity Physics and The Road. (The Road won the Pulitzer Prize, but it's not the feel good book of the year, unless the image of babies turning on a spit over an open fire makes you feel good. It's the kind of book that leads you to suddenly see the wisdom in a gun safe full of tactical weapons in your basement.) That leaves one hundred science fiction books.

One hundred science fiction books. Maybe more, but not ten times more, probably not even twice as many. Maybe less. Maybe a lot less. One hundred science fiction books spread out over the rest of my entire life.

When I arrived that estimate, it was a sobering revelation. No wonder I'm so damned picky about who and what I read. Life really is too short to read stuff I'm not really interested in.

Through a similar back of the envelope calculation, I can arrive at the conclusion that life is also too short to do work that I'm not really interested in, or not really good at, or spend time in a job I don't really love. It's too short to spend any of it with people I don't like. Bob Sutton arrived at the same conclusion through a different route in his latest book, The No Asshole Rule. Unless you happen to be immortal, a similar calculation will apply to you.

I'm currently reading The Three Musketeers by Alexandre Dumas. First published in 1844, it is a classic that has stood the test of time. Three hundred and ninety nine more to go.

Cardinal Richelieu is my role model.

Cygwin X Server under Windows Vista

The adventure that is figuring out how to do everything I do on my old ThinkPad T30 laptop under Windows XP on my new ThinkPad X61 tablet under Windows Vista continues. The latest was how to start up the Cygwin X server to I can hack my Linux servers from the new laptop.

Several other folks have reported the issues with the Cygwin fork() call under Vista in various contexts, including when running the Cygwin shell script startx. I don't have a fix for that. Instead I poked around my XP laptop and discovered that I had created a shortcut named startx that in fact ran the batch script /usr/X11R6/bin/startxwin.bat. So in short, I've never been using the stock Cygwin startx script under XP ever since I installed Cygwin on my old T30 four years ago. I have absolutely no memory of what troubleshooting I may have done back then to arrive at this solution. But it works under Vista too.

I diffed my XP batch script and the latest Cygwin batch script I downloaded and installed on Vista just a couple of days ago. The only differences are local changes: I commented out the xterm and added an xhost + just to make my life easier behind the Digital Aggregates firewall.

I am now happily using X windows from my Linux systems on my Vista tablet. As always, your mileage may vary, as testing continues.

Update (2007-12-23)

This is currently the most popular single article I've ever written for this blog, which tells you something about the pain people are going through to be productive using Vista. If you've read the comments, you know that Cygwin X server on Vista has broken for me at least once, I'm guessing due to Vista updates. What broke it, I have no fracking clue. The X server started up under Vista just fine, I could run X applications like xterm from my Linux systems or even from Cygwin on my Vista system itself, but no windows appeared on my Vista screen.

After some troubleshooting, I ended up going to C:\cygwin\usr\X11R6\bin (your mileage may vary depending on where you chose to install Cygwin), right-clicking on XWin.exe and going to Properties, selecting the Compatibility tab, and enabling Run this program in compatibility mode for Windows XP (Service Pack 2). Selecting run as Administrator not only didn't fix the problem, it kept X server from coming up at all (I got a Vista error popup).

You can be sure when my evil plans for world conquest come to fruition, things are going to be run differently.

Update (2008-02-16)

After living with my current setup for a couple of months since my last update, I find that this solution does not work reliably either. Sometimes I can get it to work again by bringing up the Task Manager, ending XWin.exe, and restarting it. Sometimes not. I tried executing the commonly cited tip of bringing up a Windows cmd window, cd C:\cygwin\bin and ash -c rebaseall (which apparently fixes some DLL address space collision issues that cause the problem with cygwin fork that originally plagued me), but to no avail.

Instead I've chucked the whole thing and have installed Xming, a native port of X to Windows that does not rely on cygwin at all. I'll let you know how it goes.

Update (2010-12-08)

Over the past couple of years I've chucked almost the whole Windows thing. I replaced Windows Vista with Windows 7 on my ThinkPad X61, replaced my daily use of that same laptop with a MacBook Air, and replaced my old IBM ThinkPad T30 running Windows XP that I had used mostly as an X window server to my Linux systems with a Mac Mini with a 27" Cinema display. I still use the X61 from time to time to run a small amount of Windows-centric software I need to run my company. But all my daily work is now all Macs with a couple of Linux servers underneath.

Chip Overclock Simpsonized

Here I am as a character in The Simpsons universe. Mrs. Overclock (a.k.a. Dr. Overclock, Medicine Woman) says I look a little like Mr. Burns. Eeeeexceeeelent! (I think she really means I remind her of Mr. Burns.)

Check out http://www.simpsonizeme.com/.

A Future Without Keyboards

My crystal ball isn't any clearer than anyone else's, but I'm beginning to think that I've glimpsed a future without keyboards. Or at least a future where keyboards will be considered niche devices by the vast majority of the population.

I've been using one Palm personal digital assistant or another for years, ever since Mrs. Overclock (a.k.a. Dr. Overclock, Medicine Woman) introduced me to them. My latest, a Palm T|X, incorporates both a BlueTooth and a WiFi radio. Somewhat to my surprise, the included web browser has proven to actually be quite usable. I routinely use the pocket-sized device to check my electronic mail, particularly while travelling without my laptop, and even to do some web cruising. Now I wonder how I ever did without it. I did buy a wireless keyboard for the T|X (it actually connects via the infrared port), but I seldom use it. What little typing I have to do I find that I can make do with the character recognition or the on-screen keyboard.

My experience over a decade ago with the very early Sharp Zaurus PDA, which had a tiny keyboard, has convinced me that such keyboards are just about useless. I want either a more-or-less full size keyboard suitable for touch typing, or no keyboard at all. My experience, mostly bad, trying to text from my Motorola RAZR phone hasn't done anything to change my mind.

Being a developer, I naturally thought about trying to develop for the PalmOS platform. Years ago I poked around a little, even tried the recommended development environment (CodeWarrior). But in the end I decided it wasn't worth my time, deciding instead to concentrate on more mainstream systems like Linux. In hindsight that was the right decision. Even Palm apparently thinks so.

Mrs. Overclock also insisted that we get a TiVo, the Linux-based DVR that so many have described (accurately as it turns out) as a life changing experience. It's easy to love the TiVo on-screen user interface. It's a remarkable UI that can please both a cynical thirty year veteran of the Coding Wars and a simple country doctor. One of the things about the UI that impressed me is how functional it was using just the "peanut", the TiVo remote which has not much more than a numeric keypad, some arrow keys, and a select button. I routinely find myself "typing" in the name of a television program using just a few presses of these simple controls. Keyboard neither required nor necessary.

My friend and embedded wonk Todd Blachowiak put me onto the Nokia N800 internet appliance. This is a pocket-sized device not much bigger than the T|X that also includes BlueTooth and WiFi radios, an FM tuner, a CCD camera, two speakers, a microphone, a microphone and headset jack, and it runs Linux. Digital Aggregates recently purchased one of these gadgets, and I am in the process of setting up a development environment (all open source of course) in the secure underground corporate data center. (Okay, I'm downloading some tar balls onto one of the Linux servers in the basement.) A BlueTooth keyboard is a common accessory for the N800, and in time I'll probably buy one. But so far I've been doing okay without it. I can easily see using this device as an FM and Internet radio, an MP3 player, a VoIP phone, a camera, an RSS reader, a web browser, and an email client. All without a keyboard.


You know how sometimes you hear a new word, then suddenly it's like everyone is using that word in every other sentence and you wonder how you, who considered yourself at least basically functionally literate, are only just now noticing this? This happened to me recently with tablet PCs.

I figured tablet PCs were a real niche until I spend four months working with a developer who used an HP tablet PC on a daily basis. Mike Dierks had a keyboard for his tablet at home, but routinely brought just the tablet to work, and happily used it to take notes in meetings, cruise the web, and review documents, all without benefit of QWERTY. He told me tales of another developer he had worked with that used a Fujitsu tablet as his daily link to the digital domain. Then Mrs. Overclock attended a conference where she talked to another physician who was taking notes on a Toshiba tablet.

It's like y'all decided to throw a tablet PC party, and you didn't invite me.

My experience with the T|X, TiVo, and the N800 were enough to get me thinking about a future without keyboards. Doing without a keyboard suddenly started to seem, well, doable. Oh, sure, I still need a keyboard, and a decent one at that, for a lot of important stuff. Stuff like blogging and coding. But for much of the other stuff for which I use my laptop, I don't need a keyboard at all. In fact, much of the time, the keyboard is just in the way.

So I decided to put my money where my mouth was. Actually, I decided to put my employer's money where my mouth is. When it came time for the company to refresh my ancient but beloved IBM ThinkPad T30 laptop, I chose an Lenovo ThinkPad X61 tablet to replace it.

The X61 tablet is both a laptop and a tablet. It opens like and can be used as a conventional laptop. In this mode it fits in the ultra-portable category, weighting in at about four pounds depending on the battery. But the screen can pivot 180 degrees and fold down flat against the keyboard, forming a tablet. It's screen uses Wacom digitizer tablet technology, and a digitizer pen pops out from its hiding place beneath the keyboard. I love the fact that I can use it conventionally to enter text and code, but then in a few seconds convert it to tablet mode for convenient web cruising.

When using Google Reader to keep up with my RSS feeds, the tablet absolutely rocks. It's as if BoingBoing and Stuff On My Cat were published in a book. A high resolution, high contrast, interactive, multimedia book. I feel like Dave in 2001: A Space Odyssey. Reading Salon is like reading a magazine in meatspace. I'm just glad we have WiFi coverage in the bathrooms.

I won't bore you with an in-depth review of the X61 (I love it; the jury is still out on Windows Vista). Those are available elsewhere. Perusing tablet PC sales figures published on the web, it's hard to draw any conclusions, except maybe sales are "slowly gaining momentum". So this probably falls under the "90% crap" that is the subtitle of this blog. But I think I have seen the future. And tablets (particularly convertible tablets, like the X61) are it.

Update (2008-07-08)

And now a comment from the loyal opposition (which would still be me). Digital Aggregates recently purchased the new Nokia N810 Internet Tablet. Its major differences from the N800 is that it has a GPS receiver and built-in maps, and (more pertinently) a slide-down QWERTY keyboard. I admit that the addition of the keyboard (and the GPS) make it a more functional tool for traveling, particularly sans laptop. The N810 is actually a little slimmer than the N800. It fits nicely in a small briefcase, courier bag, motorcycle tank bag, or carry-on bag.

Update (2009-10-26)

Just a couple of quick updates.

Windows Vista has pretty much been a major disaster for me. Unstable, unusable, and very very very slow. So much so that about a year ago I replaced my ThinkPad X61t with a MacBook Air as my principal laptop for everyday use and for travel. I have never regretted it.

But I kept the ThinkPad around because there were a few applications that I couldn't or didn't want to migrate to the Mac. This past weekend I did a clean install on the ThinkPad of Windows 7. With just a minor effort I have made the ThinkPad much more usable, faster, and (so far) much more stable. The tablet functionality even seems to work (although I've barely had enough time to do some simple tests).

Give the horror that was Vista, I am kind of impressed.

I also recently upgraded my old Motorola RAZR mobile phone. Given this article you might guess I upgraded it to an iPhone, or a Palm Pre, or maybe an Android. Nope, I went with a Blackberry Tour 9630. Yeah, that's right, a smartphone with a tiny hardware keyboard.

There were a few reasons. I needed a phone with internet and SMS capabilities. My provider is Verizon, and I wanted to stay with them. But the most difficult issue was I wanted a world phone, a phone that would work with both CDMA and GSM, the two predominant cellular standards. The only phone that fit my globe trotting requirements was the Tour.

So far I've been quite happy with it. I was able to keep on top of my email on a recent trip to Montreal and Quebec City. Coverage was adequate even recently in parts of southern New Mexico.

I'm sure I'll upgrade sometime to a smarter-phone with a touch sensitive screen. But the Blackberry meets my needs for the time being.

Update (2010-08-09)

I just recently replaced my Blackberry Tour with the Blackberry Bold 9650, which as the model number might suggest is a really a Tour II. The Tour was the greatest tool since sliced bread for travel, including overseas travel. But I fell victim to the hideous mechanical trackball that struck so many other Tour users. The headphone jack on my second Tour quit working, and that was the last straw. The Bold has everything the Tour has, including CDMA, UMTS, and GSM capabilities, plus WiFi. Best of all, it replaces the mechanical trackball with an optical trackpad. Like the Tour, the Bold has a real (tiny) keyboard.

The Bold is great for phone calls (in the U.S., England, Australia, and New Zealand, as I was to find out) and for keeping up with electronic mail. The browser kind of sucks, partly because it is very slow, and partly because of the tiny screen. (To be fair, the smalls screens on the competing smart phones aren't any better for my middle-aged eyes.)

I recently also became an avid user of a Apple 3G iPad. I recommend the 3G model even if you aren't planning on getting AT&T data service (although I did), because the 3G chipset includes a GPS unit which the WiFi-only model iPad lacks. The GPS alone is worth the extra bucks, to me anyway. I mostly love the gesture interface of the iPad, but typing anything of any length on it is painful with the on-screen keyboard. There is a real keyboard available for the iPad, but I have resisted buying it. If I'm going to cart around the iPad plus a separate keyboard, it's easier for me to tote my slim and light MacBook Air laptop. The Air has WiFi, of course, but I can also tether it to my Blackberry for Internet access over the cellular network. The iPad has a larger display, and is superior for web cruising, and it is acceptable for basic email. But it will never completely replace my Air, from which I can print and which supports Flash, neither of which the iPad supports. Sometimes I travel with the iPad, sometimes with the Air, depending on where I am going, for how long, and what I am going to do with I get there.



The war of keyboard versus no keyboard continues.

Update (2012-12-18)

I had been doing a lot of low level development on the Android platform using both a BeagleBoard and the Hardkernel ODROID-A4 Samsung Galaxy hardware reference platform. So it only seemed appropriate that Mrs. Overclock give me a Samsung Galaxy Tab 2 7" Android tablet for my birthday last year. Thanks, Mrs. O! The smaller form factor has been a hit. While I frequently travel with the larger iPad, the smaller Tab fits well in the messenger bag I typically take to customer sites. I have customers who are using the Google cloud for a lot of infrastructure services including electronic mail, and the Tab integrates well with those.



I have been well served for years by a series of Blackberries. But recently on a trip, my Blackberry Bold failed me in a minor but severely annoying way: the alarm clock app failed to go off two mornings in a row, allowing the jetlagged-me to oversleep. Nothing like that mad scramble to make a breakfast meeting. Subsequent testing has suggested that this wasn't pilot error on my part, but likely some weird software bug. I am very unforgiving about some things.

So a few days ago I walked into the local Apple store and walked out thirty minutes later with a Verizon iPhone 5, a device which like the Bold groks both CDMA and GSM, plus WiFi, and also serves as a WiFi hot spot to use with my tablets and laptops. And I bought a nice alarm clock app for it, which I have tested at home before I rely on it on a trip.



Both of these devices have soft keyboards. I'm not an expert at using the tiny soft keyboard on the iPhone, but for what I use it for, I find it completely acceptable, particularly in landscape mode.

Update (2013-02-02)

And once again, my loyal opposition speaks.

I continue to believe that the trend for information production and consumption will be increasingly cloud based. If you are as old as I am -- and I am so old that I'm basically a brain in a jar connected to wires and tubes -- you will recognize that this pattern has happened many times in the past.

If you are just slightly ancient, you will remember thin clients supporting windowing systems like X11 talking to remote servers. A little older, then maybe you used diskless Sun workstations that relied on Sun servers you may never have had a reason to see. If you are really  ancient, you may recall IBM 3270 terminals talking to distant IBM 370 mainframes. And if you are spending all of your time sitting in a rocking chair feeding squirrels, you might even have used remote card readers feeding batch jobs to IBM 360 systems far away and behind locked doors. I used all of these things at some point in my career.

And all of those trends came and went for good economic, technical, cultural, and political reasons, as market pressures cause a continual cycling between centralization and decentralization. So when I say this trend of increasingly mobile, wireless, handheld devices talking to vast cloud-based server farms will continue, I mean until something changes.

Part of this is being driven by the fact that most people use the internet to consume content, not to produce it. But if you are a content producer -- and by content I mean anything from articles for magazines behind a paywall to commercial graphics to web comics to short films to complex software systems -- then you may be in a niche that needs specialized tools. For me, who am called upon to slam out code from time to time, that means a big display, a finger-friendly keyboard, and an exceptional mouse.



So here's what my desktop development environment in my home office -- which is better than what I am provided at any client site -- has looked like for some time now. Counterclockwise from the top: an Apple Mac Mini used mostly as a window server, a big beautiful 27" Apple LED Cinema Display, a relatively gigantic Matias Tactile Pro keyboard (based on the original 3270 electromechanical keyboard, itself based on the old IBM Selectric typewriter keyboard), and a wireless rechargeable Logitech Performance MX mouse.

I've heard people say "I do a lot of typing and I do just fine with my iPad". That's crap. What they mean is "I answer a lot of email with short replies and I do just fine with my iPad". If called upon to write the equivalent number of keystrokes in Leo Tolstoy's 1500 page War and Peace (or, more recently, Neal Stephenson's 1000 page REAMDE that Mrs. Overclock is reading right now), they will quickly find out that the iPad is sorely lacking in the content generation department. That is, if their eyes and fingers survive the experience.

There are some jobs that will always require a good keyboard.

Red, Yellow, Green, Blue

I'm not a huge advocate the various formalized personal organization methodologies, like Getting Things Done (GTD), or the Forty-Three Folders (one for every day of the month, and one for every month of the year). I approach organization like I do software development processes: just enough to get the job done, and no more. Also like software development processes, I don't believe a single organization methodology works for all people and all situations.

Mrs. Overclock (a.k.a. Dr. Overclock, Medicine Woman) introduced me to what OfficeMax calls Durable Poly Color File Folders. These are flexible plastic file folders that come in four colors: red, yellow, green, and blue. I use these to organize paperwork in my briefcase for either day-to-day work, or for travel. My system is based on just the file folder colors, no explicit labels. This appeals to the most primitive parts of my brain, requiring virtually no higher level cognitive functions. For me, this is a good thing.

Red: the red file folder contains stuff that I absolute have to get done today. If I have a form I have to give the HR person at work, it goes in here. If I have bills to mail and I'm not stopping by the mailbox immediately, they go in here. If I have notes for a meeting I'm going to, they go in here. If I have a CD-ROM or even a USB drive of a presentation I'm about to give, it goes in here. I look in the red folder during the day to see what's left undone. If I get home at night and there's still something in the red folder, I know I've screwed up somehow, and it stays in the red folder. Red means Important!

Yellow: the yellow file folder contains stuff that I may need in an emergency. When I was pretty much doing nothing but field technical support and handling customer escalations, the yellow folder contained lists of super secret field service passwords, work, home and mobile phone numbers of every subject matter expert and manager in existence from which I might need help, any scrap of paper or digital media that I might need while working a customer problem. Since I'm not doing that anymore, the yellow folder still contains mostly things like company directories of my clients, contact information, and the like. Yeah, a lot of that stuff is on both my laptop and my PDA too, but I've learned not to trust anything that needs power for real emergencies. Yellow means Caution!

Green: when I travel, the green file folder contains all my travel documents: flight schedules, rental car agreements, reservation confirmation numbers, street maps, anything I might need enroute to get me where I'm going. At home, it contains forms I find useful: blank timecards, certification from the State of Colorado regarding the status of the Digital Aggregates Corporation (frequently needed by the contract administrators or HR people at my clients), a few copies of my resume, and still some Denver or Boulder street maps. Green means Go!

Blue: the blue file folder contains stuff I've printed off the web, white papers, journal articles, anything that I want to read and might have time offline in a spare moment to do so. Most of the stuff that is in this folder gets tossed after I read it unless it seems important enough to file away. A lot of this stuff I can read online, but I find I have a lot of slack time offline while waiting for one thing or another, or just prefer to read at the local coffee shop without having to tote a laptop around or pay for wireless access. The stuff in this folder has a high rate of turnover, as you might expect. If I want to travel light and expect I'll have some reading time, I'll just grab the blue folder out of the briefcase and take just it with me, secure in the knowledge that it'll have something in it worth reading. Blue means Cool!

Why plastic? They're much more durable than the cardboard folders which also come in colors but which damage easily in my rough-and-tumble experience. The plastic folders, for me, have been indestructible, and protect their contents against the occasional coffee spill, beer mug condensation, or lead spray from tactical shooting. It's a simple system that's worked for me.