Showing posts with label Macintosh. Show all posts
Showing posts with label Macintosh. Show all posts

Wednesday, December 4, 2013

Designed by Apple

Apple’s Designed by Apple video is a tad pretentious, but I largely agree with its theme. Good design, however intangible, adds value to a product whether it’s greater productivity from software seamlessly integrated with hardware or the delight of using a device that just works. I can’t tell you how much the comfort in a comfortable chair is worth, but I know it’s worth something.

To its credit, Apple has a pretty good track record of designing great products, but sometimes they completely blow it.

Take the Airport Time Capsule.

Seriously, take it; I don't want mine anymore. In fact, I wish Time Capsule had a feature that allowed me to go back in time and reconsider purchasing it.

After a recent upgrade mishap, I had to restore my computer’s data from my Time Capsule (which is basically a WiFi base station combined with a hard drive that allows you to wirelessly backup your computer’s data using Time Machine, Apple’s incremental backup software). After letting the process run overnight, this was the amount of progress that had been made:



Seriously? Five days to restore around 300 GB of data? And to make things even worse, there was another 200 GB of data that needed to be separately restored from Time Capsule. Even after a trip to the Apple Store for advice, it took another four full days to completely recover everything.

Five wasted days, all because of poor design decisions.

Apple’s biggest mistake was making this device in the first place. Wireless backup for the amount of data on a computer is just not fast enough to be practical without annoying drawbacks. Even Apple recommends that the initial backup of your computer be done using an ethernet cable because it “may take overnight or longer, depending on how much data you have.”

For the price of a 3 TB Time Capsule you can instead buy unobtrusive 1 TB USB powered hard drives, one each for up to four computers. Time Machine works significantly faster when directly connected to an external hard drive. So much faster, that after my own experience I draw a blank thinking of a situation where I’d recommend Time Capsule.

I thought I’d set mine up efficiently when I originally bought it. It was directly connected via an ethernet cable to my iMac, which I use daily for most of my work, and I planned on backing up my MacBook, which I use infrequently, connecting via WiFi.

I was wrong. Even though there was a direct connection from the iMac to Time Capsule, it was using a much slower WiFi connection to transfer data. Eventually I was able to configure Time Capsule to use the ethernet cable, but that was after four days of waiting for restores to complete.

It should have just worked. I don’t care how Time Capsule is configured, if it’s connected by a cable with a faster transfer rate, it needs to use the damn cable.

Time Capsule is both a WiFi base station and a backup device. If it fails as a WiFi base station, I can easily replace it with another WiFi base station. But if it fails as a backup device, I have no recourse. I can’t easily replace the data stored on the device.

The design of the device should have made creation and recovery of a backups fast and dead simple. Zero configuration. If that meant fewer options in configuring it as a WiFi base station, that’s the call that should have been made. Instead, I had to browse internet forums looking for hints on how to correctly configure the device. Even after managing to get my data restored, I still have no idea how to configure it properly for the manner I originally intended to use it.

Finally, even the smallest details matter in design. Time Machine warns you if it hasn’t been able to perform a backup for an extended period of time. It should also warn you if it detects a Time Capsule connected by an ethernet cable that it’s not correctly configured to use. I doubt that’s technically complicated, but even if it is, here’s something that’s even simpler. During the four days I was waiting for my data to be restored, this message should have been displayed:
Restoring “Giganto” via WiFi on the disk “Giganto”
Just two small words would have helped me to figure out why something that should just work wasn’t working.

Here’s what Steve Jobs had to say about design:
“That's not what we think design is. It’s not just what it looks like and feels like. Design is how it works.” — New York Times, The Guts of a New Machine, 2003
Apple, the way your Time Capsule works sucks.

Monday, September 16, 2013

Changes

When change happens gradually over a long period of time, it’s easy to lose sight of how far you’ve come from where you started. When I first started working with CLIPS in 1985, I used the monkey and banana (MAB) problem as a benchmark for improving performance of the rule engine. The original version had 20 rules, 5 initial facts, and executed 14 rules. To make the program a bit more complex, I added chests and keys so that objects could be locked away and the monkey required additional planning to gain access to them. This extended program had 32 rules, 13 initial facts, and executed 81 rules. It’s a toy problem and today it seems silly that I used it for benchmarking anything, but it was at the time invaluable in improving the performance of CLIPS as well as comparing the performance of various rule engines and hardware platforms. The usefulness of this benchmark is more apparent if you view it as measuring best case performance rather than performance under load as other benchmarks such as Manners and Waltz measure.

In 1986 even the state of the art Automated Reasoning Tool (ART) software running on expensive Lisp machines executed MAB at only 72 rules per second. CLIPS running on a VAX-11/780 clocked in at 16.8 rules per second and OPS5 on this same platform executed 62.3 rules per second. When I first got CLIPS running on an IBM AT, execution speed was less than 1 rule per minute. You read that right—it took over an hour for the monkey to get his hands on the banana. CLIPS dynamically allocates and deallocates memory as it executes and in those days—when memory on PCs was more often measured in KB rather than MB or GB—the memory allocation libraries were often painfully inefficient. It was only after I removed some of the unnecessary allocations/deallocations and had CLIPS cache deallocated memory that I was able to improve the performance to 4.3 rules per second.

Over 25 years later, CLIPS clocks in at well over 100,000 rules per second running MAB on my laptop. Think about that for a minute. That’s over 25,000 times faster. Twenty. Five. Thousand. And most of that, at least for MAB, is attributable to the hardware (and possibly the compiler/operating system), not improvements to CLIPS (which at most might have improved performance for MAB by a factor of 2 to 4 times). Consider that improvement in terms of the problems you can solve today that you couldn’t solve 25 years ago.

And it’s not just that hardware is faster—it’s also cheaper. I was downright ecstatic when I got a Macintosh IIfx in the early 90s at NASA. Programmers hate waiting for code to compile so we always want the fastest computer available. At the time the IIfx was “wicked fast” with a 40 MHz CPU and up to 128 MB of memory. It also had a hefty price of around $10,000 (roughly $16,000 in today’s dollars adjusting for inflation). After I left NASA and was working from home, I bought a Mac clone from Power Computing in 1997 for $4700 (roughly $6700 today). Since that time, my desire to have the fastest computer available has melted away as the lower end computers became fast enough for almost everything I do. The last desktop computer I bought was an iMac in 2009 for $1500 (roughly $1600 today). It came with a 2.66 GHz processor and 4 GB of memory. I upgraded to 8 GB of memory in 2011 for around $115 when I started running Windows in a virtual machine. Occasionally there’s some sluggishness when switching between the virtual machine and Mac OS X—which could probably be fixed by adding more RAM (if alas the computer weren’t already maxed out)—but for the most part this computer still feels new.

Usually after around four to five years, as the operating system and applications introduce new functionality that increasingly taxes the hardware, sluggishness becomes noticeable to the point that it’s easy for me to justify a new computer based on productivity alone. Yet I’m at the point where I usually start thinking about a replacement, but feel no serious need for one. If I feel that way and use a computer most of the day for programming, I wonder how the average consumer feels about replacing their computer when all they do is use it for activities like email and surfing the web. Obviously traditional computers (desktops and laptops) aren’t in danger of extinction, but if I were a company that just made these devices (and not smart phones and tablets), I’d be worried about my long term profitability.

Which gets me back to my original point. We had computers 25 years ago and we have them today, but boy have they changed. With smart phones, we literally walk around with computers having tricorder like functionality in our pockets. What will I be comparing these devices to in 25 years?