Mitch's Blog

Do you find yourself saying things that are so absurd you’d not believe it if you hadn’t lived through it? I’ve had a few of those experiences.

I once worked at a software company that had a strong unit test culture. There were specifications for everything and tests for everything. Sounds great, right? Unfortunately, despite extensive review meetings, the specifications never survived the few first days of coding. The unit tests were detailed and thorough–fantastic! But no one ever ran the whole product in-house. QA didn’t. Developers didn’t. The company didn’t use its own product because “it is too complicated.” After I left the company, I had a problem that the company’s product was designed to solve. As a shareholder, I was interested in the company having customers, and happy to be one. I downloaded the product and installed it. When I fired it up, the product crashed about 3 lines into main(). No one had ever used the product. It’s great to prove that the pieces work individually, but your customers will be using them when they are all bolted together. You have to make sure the holes line up.

I also once worked at a company with the exact opposite approach. There were no unit tests of any kind. No libraries, no modules, nothing. The only way to test anything was to run the product. This meant there were very few crashes on the third line of main(), but it also made it impossible to know whether or not any of the pieces of the code work independently. If you can determine whether pieces work independently, you can track those results, tie them to check-ins, and suddenly understand a heck of a lot about what changes in your source control impacted what areas of the product. You can track down not only data corruption but also which modules hit performance issues, whether within a unit test context or within an integration context within a customer environment.

The first company had a hard time getting customers to be successful with the product. The second company had difficulty predicting when a release would be ready. The former is easier to fix–start using the product internally and also fix the QA organization to include system tests. The latter likely entails an expensive refactor and reflects deeper cultural issues of a hacking organization rather than an engineering organization. Neither extreme is healthy.

How many times have you seen the UPS landing page below?

Why is it that neither FedEx nor UPS know about geolocation of IP addresses? Even if geolocation was used just as a hint or an obvious way was provided to change it if the geolocation went wrong, far fewer folks would hit these screens. And after you make a selection, the UPS site just sits there and does nothing until you click the small blue botton.

I hate software that makes me deal with pop quizzes and stupid modal dialogs. Hey, where are you? Would you like fast or small? Want to update now? Restart Firefox now? Hey, you will need to reboot after you install this, OK? Downloading this RPM will use 30 KB of disk space, sound good? Really quit? There’s an item on your calendar coming up in 10 minutes, you won’t be able to click anywhere in Gmail until you click this OK button… on all of your computers. I couldn’t copy that to the clipboard. Send a bug report to Apple? This document has ColorSync profile 1, and this other one has ColorSync profile 2. Would you like me to alert when submitting a form to an unencrypted site? There was an error with your request, try again later. All the downloadable content has downloaded. I am going to go ahead and join you to the unsecured network ‘linksys’. Hey, couldn’t backup this computer. Holy shit, there’s new software available, I don’t care if you’re watching a movie fullscreen (iTunes + Notification Center). Psst, mind if I phone home real quick? Oh, by the way, the iTunes terms and conditions have changed and I suddenly can’t remember your credit card number.

Who wouldn’t hate a machine that talks to you this way, all day, every day? I am trying to get some work done here, and you’re telling me all this out-of-band shit and very little of it is useful to me right now.

Please stop asking me questions. I don’t know what the answer is and you’re interrupting my train of thought, which I value far more than pondering any of the above questions.

There are lots of examples of how to use the Ethernet Wiznet chips with Arduino, whether as Ethernet shields or as Ethernet Arduinos on a single board. Unfortunately, most of these examples hard-code the hardware (MAC) address, which can make things painful if you’re building more than one device and running them on the same network.

The code snippet below is a more convenient approach. You can setup a prefix (DEADBEEF in the example below) for the hardware address and the last two bytes are set randomly on first boot. The hardware address is stored in EEPROM (7 bytes are needed, 1 for a flag indicating that the next 6 bytes are properly populated).

The bytes->String conversion below is a bit ugly but I didn’t think I wanted the overhead of sprint in this. It is probably not worth the trade off. (0×30 is ’0′ and 0×39 is ’9′. Adding 0×07 skips over some ASCII characters to ‘A’.)

Some serious caveats: There’s only two bytes of randomness here. You might want more. Ideally you would have a manufacturing process, but if you’re just building six devices, who cares? Clearly you would never use this approach in a production environment, but it’s easier than changing the firmware for every device in a hobby environment. You could also use a separate program to write the EEPROM hardware address and keep this “manufacturing junk” out of your main firmware. These issues aside, my main requirement is convenience: I want to be able to burn a single image onto a new board and be up and running immediately without having to remember other steps. Convenience influences repeatability.

#include <Ethernet.h>
#include <EEPROM.h>

// This is a template address; the last two bytes will be randomly
// generated on the first boot and filled in.  On later boots, the
// bytes are pulled from EEPROM.
byte NETWORK_HW_ADDRESS[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0x00, 0x00};
String NETWORK_HW_ADDRESS_STRING = "ERROR_NOT_FILLED_IN";

// These are commented out so that this code will not compile
// without the reader modifying these lines.  If you are using
// EEPROM code in your program already, you need to put the
// network address somewhere that doesn't collide with existing use.
//#define EEPROM_INIT_FLAG_ADDR 0
//#define EEPROM_HWADDR_START_ADDR 1

// Call this from your setup routine (see below)
void
initEthernetHardwareAddress() {
    int eeprom_flag = EEPROM.read(EEPROM_INIT_FLAG_ADDR);  
    int i;
    Serial.print("EEPROM flag is " + String(eeprom_flag));
    
    if (eeprom_flag != 0xCC) {
        NETWORK_HW_ADDRESS[4] = random(255);
        NETWORK_HW_ADDRESS[5] = random(255);  
        
        // write it out.
        Serial.println("Writing generated hwaddr to EEPROM...");
        for (i = 0; i < 6; i++) {
            EEPROM.write(EEPROM_HWADDR_START_ADDR + i + 1,
                         NETWORK_HW_ADDRESS[i]);
        }

        EEPROM.write(EEPROM_INIT_FLAG_ADDR, 0xCC);
    } else {
        Serial.print("Reading network hwaddr from EEPROM...");
        for (i = 0; i < 6; i++) {
            NETWORK_HW_ADDRESS[i] =
                EEPROM.read(EEPROM_HWADDR_START_ADDR + i + 1);
        }        
    }
    
    char hw_string[13];
    hw_string[12] = '\0';
    for (i = 0; i < 6; i++) {
        int j = i * 2;
        
        int the_byte    = NETWORK_HW_ADDRESS[i];
        int first_part  = (the_byte & 0xf0) >> 4;
        int second_part = (the_byte & 0x0f);
        
        first_part  += 0x30;
        second_part += 0x30;
        
        if (first_part > 0x39) {
            first_part += 0x07;
        }
        
        if (second_part > 0x39) {
            second_part += 0x07;
        }
        
        hw_string[j] = first_part;
        hw_string[j + 1] = second_part;
        
    }

    NETWORK_HW_ADDRESS_STRING = String(hw_string);

    Serial.println("NETWORK_ADDR = " + NETWORK_HW_ADDRESS_STRING);
}

void
setup() {
    // first call the usual Serial.begin and so forth...

    // setup the Ethernet hwaddr before you start using networking
    initEthernetHardwareAddress();

    int dhcp_worked = Ethernet.begin(NETWORK_HW_ADDRESS);

    // ...
}

I have been a big fan of xxdiff for many years–so much so that I wrote a Mac GUI clone for it as a mental exercise while on vacation in 2006. Unfortunately, xxdiff with svn has always sucked–it requires awkward scripts to plug it into svn, and those don’t tie into ‘svn diff –diff-cmd ‘ very well. A buddy recommended I switch to tkdiff, and it’s not bad at all. This morning I threw together a wrapper to point my ~/.subversion/config at for 2 file diffs. Since I do a lot of work in both SSH and in X11 terminals, I wanted something that could relieve me of typing ‘–diff-cmd diff’ all day long.

#!/bin/bash
#
# Script to enable 'svn diff' as a GUI diff in X11 or a CLI diff
# on the command line (or if stdout is redirected).
#
# I couldn't get tkdiff to take a -geometry argument. I ended up
# setting my geometry in tkdiff's opts dictionary.
#
# Arguments coming in from svn diff:
#
# -u -L src/hello.cpp (revision 1234) -L src/hello.cpp (working copy) src/.svn/text-base/hello.cpp.svn-base src/hello.cpp
#

dash_u=$1
label1="$2 $3"
label2="$4 $5"
file1="$6"
file2="$7"
# echo "Comparing _$6_ and _$7_"
cmd=diff
if [ -t 1 -a -n "$DISPLAY" ]; then
    cmd=tkdiff
fi

$cmd "$label1" "$label2" "$file1" "$file2" 
RC=$?

exit $RC

Colleagues who have worked with me in the last ten years know I have some religion about appliances. To a large degree, I believe that most enterprise software that is installed in a customer’s data center should be packaged as an appliance. The embodiment of this could be as a physical appliance or as a virtual software appliance, but either way, it’s an appliance.

My sense is that appliances, especially virtual appliances, are picking up momentum. We’re seeing more and more software companies offering virtual appliances on the market today and more products that could be packaged as software instead packaged as a hardware offering.

There’s a problem though.

Most of these appliances are crap.

What is an Appliance?
It would be cliché to turn to Merriam Webster for a definition, so let’s consider what the Oxford American Dictionary says an appliance is:

ap-pli-ance n. 1 a device or piece of equipment designed to perform a specific task

So if we’re building an enterprise IT appliance, it’s going to be a virtual machine or a physical machine to perform a specific task.

In my mind I’ve always given Dave Hitz, co-founder of NetApp, credit for defining an appliance, but in this interview [PDF], he gives credit to the model Cisco established:

Hitz: [...] We were modeling ourselves after Cisco. If you look before Cisco, people used general purpose computers, UNIX workstations, Sun workstations for their routers. Cisco came along and built a box that was just for routing. It did less than a general purpose computer and so the conversation we kept having with the VCs, they would say, “So your box does more than a general purpose computer so it’s better?” And we’d say, “No, no, it does less.” And they’d go, “Well, why would I pay you money to start a company that does less?” And we said, “No, no, it’s focused. It’ll do it better.”

He continues:

The other analogy that we used was a toaster. If you want to make toast, you could go put in on your burner, you can put it in the oven and it’s certainly the case an oven’s a lot more of a general purpose tool than a toaster. A toaster? What good’s a toaster? All it does is make toast. But, man, if you want toast, a toaster really does a good job, you know? Try making toast in your oven and you’ll discover how awesome a toaster is. And that really, for storage over the network, it was that idea of making a device to do just that one thing, focused. Not run programs, not do spreadsheets, not be a tool for programmers, just store the data.

I’ve always stuck by the toaster model when thinking about appliances for customers.

So what does this mean for the user?
Let’s talk about product requirements.

When a vendor ships an appliance to the customer, everything is included: The OS, the management tools, and the application. The beauty of this approach is that the customer no longer has to install software. The customer is no longer responsible for dealing with OS patching and ensuring the right OS patches are installed that match with the requirements of the application.

The user interface should be stripped down and minimal. The user should never see a general purpose bash shell prompt. The appliance should be as self-contained as reasonable. Configuration should be as minimal as possible. IP address and related information, LDAP or user set-up, NTP and timezone, email and SNMP, application-specific coordinates, and that’s it! This can be implemented in a small X11 set-up GUI (Nasuni does an excellent job here) or a simple ncurses-based text wizard (similar to what ESXi has).

The user should never be told to edit files off in /etc or manually tweak key-value pairs to get the basic application up and running. Some application programmers get off on connecting to a customer-provided database. In a particularly large installation, this might make sense. To store 500 rows of data, it does not.

An appliance is likely Linux-based these days, as it should be. Software updates should come from an update server provided by the vendor. From the user’s perspective, there is no apt-get or yum details to worry about; it’s a simple matter of clicking a ‘Upgrade’ button. Anyone shipping a Windows-based appliance should only do so for very specific reasons (e.g., need access to Windows APIs).

The GUI for the appliance should be web-based. These days, it needs to be accessible from a variety of browsers. Product managers need to understand the average IT guy has more things to worry about than a single product, and hints need to be provided on how to find the management UI for the appliance. I love how HP handles this on their switches and I adopted their model at my last company: Every login console tty included the IP address and how to find the GUI; both shell and GUI login screens included the default account name and password, right there. The last time you installed a home router, did you have to fire up Google and search for the default user name and password? Or did you read the documentation? Did you read the documentation for Tetris? Why should the default user name and password be harder than playing Tetris?

DHCP should be the default on a first boot, and active on all interfaces with a link. Anyone shipping an appliance without DHCP in this day and age needs to get with the times.

Any CLI should be succinct and hierarchical. Enterprise IT gets tricky, no matter how we simplify it, and users need a way to drill into the available commands. The CLI needs to balance “learning” with speed of use. The reality is, most IT folks are using a lot of different products throughout the day. Make yours the one that is easiest for the admin to jog his mind on how to see replication status (or whatever).

When it comes to lights-out management, product managers and engineers must understand that the product is not the center of the end-user’s universe. Problems and reports should be available via email. With a generated email, the subject line is critical and should be succinct but descriptive. “2 alerts (product name)” with a From: field of the hostname is a good start at a subject line. Failures and recovery from failures should be as automatic as possible. Customers should never have to login to click something in a GUI that the product could have run itself to recover from an error.

Although not strictly appliance-related, let’s also talk about sockets and ports of the TCP/IP variety. When it comes to networking, products should be designed with WANs, VLANs, routers, closed ports, and different views of networks when communicating with other instances of the same product. Don’t rely on ICMP pings being available. Don’t rely on your connection target matching the listening target coordinates. Have flexibility. Design your network protocols for the simplest firewall configurations. In a spoke/hub topology, all the spokes should reach into the hub–that is, all spokes open sockets on a port the hub is listening on, even if the logical client/server is the other direction.

Shipping a Virtual Appliance
This is where I see the most sin in the market today. So many folks install Ubuntu, install their software, shutdown the VM, zip it up, ftp it over to their web site and call it a “virtual appliance”. This is a VMDK full of crap. /root/.bash_history is still populated, as are DHCP cache files, log files, and other things that should be scrubbed. There is no OVF installer file. Old snapshots of the VM are included. What kind of embarrassing stuff is in there?

Let me state up front that OVF is one of the dumbest things in the VMware world. There is no need for it to exist; everything that it does could have been accomplished much more simply. But VMware doesn’t like to make things easy, so we’re stuck with it. On the bright side, the user experience of installing an OVF appliance into a VMware environment is awesome. Thus, vendors need to use it.

From a mindset perspective, the vendor needs to get into a mental mode of a manufacturing process to scrub the VM prior to OVF packaging. Things need to be set to “factory defaults”.

With both physical and virtual appliances, the size of Linux distribution should be minimal. This is more important with the virtual appliance distribution, since customers will be downloading it. As a vendor, you can pick a few approaches on how you do this, but in general, reduce the number of packages you’re including to the bare minimum. You need to tune your CPUs and RAM to the minimum required for your application and let customers tune up from there. If you’re shipping both virtual and physical appliances, you need to understand these are different beasts. How will you sell them? My bet is that you’re pushing virtual appliances into remote-office/branch-office use cases, so size the requirements for the VM appropriately. Size your VMDKs down to something reasonable or use thin-provisioning. Note that OVFs with thin-provisioning will not work on ESX versions less than 4.1 or 4.5 (I can’t remember exactly which versions are broken for thin-provisioning with OVF).

Shipping a Physical Appliance
Ten years ago, I worked on my first appliance product. One of the problems we had with this physical appliance when we went out in the field was that we needed a screwdriver to get it in the rack. Customers sometimes had to spend 10 minutes searching for tools if they were installing it themselves. We started to include a multi-tip screwdriver with the product in the shipping carton. In 2010, my new company had the opportunity to buy a few systems from the previous company. The screwdriver was still included. If I ever do a physical appliance again, I will include the screwdriver. What’s $10 on a $50,000 system anyway? Don’t forget this is a branding opportunity–put your logo or URL on the handle.

If your system is heavy, ship it on a pallet. If you’re on the border (70-80 lbs), pay attention to the condition that the system packaging is in when it arrives at customer sites and adjust accordingly.

Pick rails that don’t suck and work in 2-post and 4-post racks.

Use fans that are quiet. Spend a bit of time to add software support to control the fans appropriately. If you own a previous product I worked on with loud fans, I apologize. I really do.

There are lots of little details to take care of to finish a solid appliance offering. The application should be monitored by a watchdog (inittab, eventd) so when it goes down, it comes back up. Log file size and rotation should be set up. Cores should be constrained if runaway coring occurs. The application should start when the appliance is booted by default. It sounds obvious, but I’ve seen a few appliances that didn’t do this. Vendors should change /etc/rc.sysinit so that when fsck fails during boot, customers are instructed to call the vendor, or dropped into an emergency shell, rather than prompted for a root password. Vendors need to abstract configuration variables set by the users from their destination /etc files. It needs to be easy for the user to back-up, reset, and re-apply configuration settings.

Where Do We Go From Here?
Lots of applications are going to the cloud, which is fantastic. We’ll continue to see more of that. But we’ll still need to have software in our data centers. And it would be nice to see much of that software shipping as an appliance. I hate installing software applications on an OS for IT workloads. It’s stupid, it’s complex, and it’s largely unnecessary. Anyone who has installed a complex application knows how stupid it can be. Installing a TSM server package on a CentOS base is a quick 200 step process and the fact that even I could make it work means it was probably pretty easy.

Over time, we might find that some of the Cloud APIs are enabling compute resources with a different layer underneath than the traditional OS. A proper API underneath that extends onto physical and service offerings that can help standardize some of these appliance computing characteristics would be wonderful, but I don’t see how anyone can make money developing such a thing, so I am not optimistic that it will come to be.

So, remember, an appliance:

• Does one thing. It is focused and minimal.
• Is stripped down. There’s no bash shell for the user. The UI is focused, concise, web-based.
• Is lights-out. It recovers from failure. It is well behaved. It handles updates easily.
• Reduces burden on the user.

Vendors need to quit shipping software junk that they call an appliance. Customers need to demand more; it’s amazing how much bad software IT has to deal with. Stop adding to the pile.

Ship something good.

Many thanks to my colleagues and friends who reviewed this post before publishing.

I resisted writing this post as long as I could. I really did. I’ve always been so excited about Drobo and everything they were doing to enable anyone to have the benefits of redundant blocks in a storage system. I was super excited when Drobo started going up-market with the introduction of the Drobo Pro a few years ago and later the Drobo Elite. It was going to be an exciting ride to see where Drobo took things.

Recently I made the mistake of upgrading to the new Drobo Dashboard, the management tool for monitoring one or more Drobo boxes. I was struggling to get my Mac Pro to see my Drobo after installing an SSD and pulling in a recovered OS configuration.

In any event, I ended up with the new Drobo Dashboard. You can tell it was designed by the marketing department because the Drobo name and logo appear at least 8 times in this screenshot. Do you think this reflects the voice of the customer? “Your UI is great, but I really wish you had the name of your company up on the screen in more places. One or two is just not enough!”

There are other problems with the look of this interface, of course–I have no other apps that look like this or behave like this (fact), it’s ugly (opinion), it’s hard to read (fact: white text on a black background is a bad idea)…. I could go on, but it’s too painful and frankly I feel bad. I’ve pumped out my share of bad user interfaces over the years, but none of them had the vendor name on them in 8 places in a single view.

2011 is just a week away now and there’s a few things I’d like to see come to the Mac in the next year.

This past year, we finally got something called ‘Outlook’ native on the Mac. It’s time that this Outlook got a few things that have been missing on the Mac for a while–for me, that means:

1. Google Apps Sync Engine for Outlook. Without this, Outlook on the Mac isn’t as exciting for Google Apps as it is for Windows.

2. Xobni for Mac Outlook. Xobni is a very handy tool and I have bought copies for it for both machines on which I use Windows. But I’d really like to have it on the Mac.

3. A Salesforce.com plug-in for the Mac Outlook. Again, we feature parity with Windows would be nice. Specifically, I want to easily tie emails onto contacts and opportunities in Salesforce.com.

In addition to these Outlook items, I have some other wishes:

4. OmniFocus needs a little email improvement. Right now, using email to send something to OmniFocus requires Apple Mail and custom rules. I’d like to see one of two solutions: (1) is to have OmniFocus check email with a dedicated account that the user configures. This seems confusing to explain to customers, so I am not sure that’s a good solution for Omni. (2) is for Omni to provide an email service, just like Evernote does. Evernote gets email integration right–just like Salesforce does–everyone should copy their approach.

5. More native DropBox support for iPad and iPhone apps. OK, this isn’t exactly Mac-specific, but I’d really like to see OmniFocus and Evernote applications able to browse DropBox contents easily. Native DropBox support for DAV as a front-end and DAV in apps with an eye towards simple DropBox integration would be handy.

6. Some better graphics tools. I use Photoshop, Illustrator, OmniGraffle; I’ve played with Pixelmator, DrawIt, and others–but somehow none of these quite do what I want for “marketing graphics”. I want the control of Illustrator and Photoshop to build widgets and something like OmniGraffle but with more intelligence to piece them together. This almost sounds like ClarisDraw… but EasyDraw isn’t the answer either.

7. More head-less and powerful virtualization. VMware Fusion guest processes are lost when the Mac window server goes away (e.g., killed via remote ssh). VMware Fusion needs support for multiple Ethernet interfaces without hacking around in random files. I’d like to see something marketed for a more professional workstation user with more of the Workstation features. I’d be happy to see a Fusion Pro or something at a higher price point if that is what’s needed.

8. VMware VI Client without having to run a Windows virtual machine in Fusion or investigate awkward WINE stuff.

I have some other wishes as well–I’d like to see Apple fix the broken iTunes sync with devices and limits around a single library. For example, music I buy on the road I cannot sync to an iPod or iPad or iPhone, since they all sync to my desktop–and my 256 GB MacBook Air isn’t big enough to hold my 1 TB iTunes library.

Recently I spent some down time playing with some new utilities to see what’s out there that might help me. I’ve added the following tools to my Mac toolbox:

TotalFinder ($15) — This is a plug-in for the Mac Finder that adds tabbed browsing and some other nifty hacks, such as a “two-up” tab view for looking at two directories concurrently in the same window. Finder window management has been a mess for 26 years, and perhaps a real problem for me for the last 20 years, so it’s nice to see someone working on this.

SecondBar (free) — This puts a second menubar up on a second monitor. Unfortunately, the name reflects reality–it only provides 1 more menubar, and not one per additional screen. However, it works well for what it does. I tried some other menu utilities, but they all miss the boat for my needs.

BetterTouchTool (free) — This does a number of things with the Magic Mouse that didn’t seem very useful to me. However, it also provides Windows 7-style window snapping, which is one of my favorite Windows 7 features. And it works better with multiple monitors than the Windows 7 feature does.

StoryMill ($50) — The killer feature for StoryMill is the full-screen mode. It’s significantly better than what Word or Pages have for full-screen and makes writing prose much easier for me. Of course, it brings a lot of organizational tools for writing very long documents (books!) as well. I love using StoryMill for cranking out raw text to be edited later.

Kaleidoscope ($40) — This is a very cool differ. There are certain things that I miss from my own differ, RoaringDiff, but my favorite part about Kaleidoscope is that I don’t have to fix the bugs. I just started looking at Kaleidoscope today, but expect I will be registering soon once I’ve confirmed that the CLI entry point will work well for my svn workflow.

Evernote (free or $45/yr for premium) — I’ve been using Evernote for a while now. Recently I added two new pieces to my Evernote ecosystem. One is that I’ve configured the email address book on my multi-function printer/copier/scanner like this one (the one I have is no longer available) so that I can scan paper into Evernote with 4 button clicks. The other is that I bought FastEver Snap ($2) for my iPhone, which lets me photograph whiteboards and upload them to Evernote immediately without having to take explicit action.

Last night, I was ranting on Twitter again.

This time it was about task management software. There’s several options out there, but everything I’ve looked at has fundamental flaws. I’ve settled on Remember the Milk for now, but I’m not thrilled with it.

Here’s what I want:

• A clean UI that is fast and optimized for brain dumps of a large number of tasks. Smart tag management.
• Mac-native application.
• A web UI for when I don’t have my Mac handy.
• Storage in the cloud and locally. I want to use it when the cloud is down, when my connection to the cloud is down, on the subway, etc.
• I don’t want to bring my own cloud service. I want to buy a service that someone else runs.
• Integrate with Google Apps: My calendar should show deadlines, the task system should have access to my address book, etc.
• Good iPhone application with emphasis on new task capture and the ‘next’ to do list.
• Nice to have — Outlook for Windows plug-in to sync tasks into Outlook’s to do. I use Outlook 25% of the time for Xobni.
• Nice to have — Integration with BaseCamp. I don’t use the To Do stuff there much, but people assign me tasks in BaseCamp. It would be nice to see those in my To Do list (and be able to click to go to them in BaseCamp).
• Nice to have — Integration with Salesforce. Again, tasks are created in Salesforce and I’d like to see those in my central view of the world (and be able to click to go to them in Salesforce).
• Nice to have — Show today’s calendar item from Exchange / Google Apps. This is particularly important when planning what to do next and identifying how much time I have from now until my next commitment. I often flip back and forth between calendar and the to do list. Neither Outlook nor Google Apps get this view right.

Here’s what I’ve tried:

• Things — I have bought Things for the Mac, iPad, and iPhone. However, after it trashed its database and tech support basically told me “I don’t care”, I haven’t been able to get back into it. Fundamentally, it is missing cloud sync, which makes it somewhat useless for someone who travels a lot. My corruption seemed to be related to syncing with the iPhone, which doesn’t inspire much confidence and so I would stop syncing with the iPhone. However, the Things UI is almost perfect. No one else seems to hold a candle to it.
• OmniFocus — I tried it a few years ago when it came out, but it was riddled in complexity and not as smooth as Things. This might be fixed now. I would like to try it again, but Omni doesn’t offer a production cloud service yet. I generally like Omni products.
• Remember the Milk — I like that I can use it from any computer. However, it’s tedious for dumping in a lot of tasks. Setting a new location on a task requires a manual step of creating a new lcoation. Why can’t I just type in my own locations and let it sort them out? The details for a task are presented on the right side of the window, rather than right next to the task, which leads to a lot of mousing around. In fact, the whole UI is about mousing around and a lot of clicking. For example, I have a task with some notes. When I click the task, it shows that I have 1 note, but I have to click again to see it. Just show me everything. I’d like something that I can control entirely from the keyboard. However, the iPhone app is quite decent based on a cursory examination. No Outlook integration.
• Evernote — Not really a task management system, but I had heard of people using it as such. Great for what it does, not great for task management. But the cloud service, native apps, and sync model are all perfect.

I will keep plodding along with Remember the Milk for now, but I’d really like to see a Things-like UI for Remember the Milk, either as a sophisticated JavaScript UI or a Mac application. For busy professionals, task management is a huge tool and nothing seems to get it right. There’s a market hole here that someone needs to fill. Several people have asked, “so why don’t you write it?” I am very busy with another software company right now and one at a time is the maximum for me.

P.S. If you know of a solution that I missed that might work better for me, I’m all ears! mitch.haile@gmail.com