“In Defense of Hard: When Easier Isn’t Better”

Before I sold it, Project Badger was ugly. Almost painfully ugly. It wasn’t a deliberate decision — I’d have made it pretty if I’d had the time — but our customers wanted what it did, not how it looked.

When BigCo bought it, the first thing they did was slap a new name on it and hire a guy to build a new interface for it. I wasn’t enamored of the “new name” idea, because it had a good reputation and a following of thousands of customers under its original name, but I was all for a nicer interface.

After six months, the guy had built a very pretty interface. Unfortunately, it was crap. It only really worked at 1024×768, the resolution that that developer preferred (I was stuck at 800×600 on one of my machines at that point, as many people were, and it was all but unusable at that resolution). It simplified some options to the point of uselessness. But worst of all, under the hood, the guy had taken so many shortcuts that fixing its shortcomings would have required completely rewriting it from scratch.

Many customers who tried both preferred to use the original interface, despite its ugliness — a damning indictment.

Easy isn’t always the best answer. The original program was complex, and required the person using it to study the options available and make choices; simplifying it reduced the choices and made it easier to use, but also destroyed a good portion of its usefulness. And as another facet, by taking so many “easy” shortcuts in the new interface’s design, the developer had made it all but impossible to improve it.

There are trade-offs in everything. An oak tree takes a long time to grow, but its wood is dense; a pine tree can grow quickly by not spending so much energy on its structure. Furniture made of pine is much lighter, easier to build, easier to move, and less expensive, but furniture made of oak lasts. You’ll notice that oak furniture is still around.

There’s a reason why doing something the hard way is often preferable.