Wednesday, September 24, 2008

Remote Usability

broken remote control Ever since I read Don Norman's The Design of Everyday Things, I've been hyper-sensitive to things that have really poor usability. His classic example is doors: how often to you walk up to a door that has handles on both sides, tricking you into pulling instead of pushing? Doors like this require an instruction manual: "Push" or "Pull". But the problem is that, if it's a glass door, you'll read the backwards word through the glass and still do the wrong thing. It isn't you, it's the door. If something as simple as a door requires a manual, it's really poorly implemented.

Here's a recent case of something simple whose usability is so profoundly broken it needed a manual. I spoke at TechEd this year. They are one of the conferences that absolutely require that you use their machine for your presentation. On the stage, they had a remote control to use for your slides. It looks like the image to the left. Normally, the button the right moves to the next slide and the left button moves you one slide back. Yet this stupid remote reverses that. Of course, you can turn it upside down, but it clearly had a right-side up. To fix it? Someone affixed labels to it to fix the utterly broken usability.

As developers, we need constant diligence for usability. While it probably made perfect sense to some remote control creator because of the electronics to put the buttons on the wrong sides, but it ruins the usability. If a 2 button remote can't get this right, what hope do we have when building a rich client?

Tuesday, September 16, 2008

SOA (Sidekick Oriented Architecture)

Warning: smiling broadly or laughing out loud while reading this will expose your age to those around you.

When Microsoft released DOS 3.3, they added a much requested feature: background printing. That was the state of the art of cool back then: at the time, DOS was a single-process operating system, and users complained that they couldn't do anything else while waiting for something to print. Thus, Microsoft added the print spooler. But that opened a can of worms, because other software companies (like Borland) reversed engineered what it did and built applications around it. The way it worked was by chaining to a low-level interrupt in the underlying plumbing of the operating system. Borland exploited this to create a massively useful little utility called SideKick. SideKick was awesome. While working in an application, you could hit a hot key and pop up SideKick, make a calendar entry, browse the file system, and lots of other stuff. Then, with a hot key, you were back in your application. This was old-school multi-tasking: incredibly primitive, yes, but oh so useful. This category of tool was categorized as a TSR's (Terminate and Stay Resident) application.

Of course, you can imagine what happened next: everyone and their brother built TSR's. And if you weren't careful with your interrupt chaining, the whole house of cards came crashing down. This became an annoying issue in the dying days of DOS. Windows rescued us because it had an event driven architecture, and you could run multiple applications at the same time. Of course, Windows was really just running on the shaky DOS ground, but it allowed developers to take advantage of the event driven system automatically and stop fighting with other applications over interrupts.

The problem with the TSR approach was the fragile high coupling it required for the limited resource of operating system interrupts. We know now (and then) that highly coupled systems are fragile. Yet we seem to never learn that lesson.

Look at the state of most "enterprise" applications today. You think you have 5 different applications that share the same database. In reality, you have one massive application, partitioned at the application layer but still highly coupled once you get to the database. It's hard to make changes to the shared database without breaking (or at least looking hard) at the existing highly coupled applications. In hindsight, I think we're going to regret the way we've tended to use databases in large corporate environments. Part of the problem is the myth of a single source of knowledge throughout the enterprise. I've talked to a bunch of CIO's who say "I don't care what you do in the applications you build, but my database schemas are precious". This is a short-sighted view of how to build flexible architectures. Much of the work done now in SOA is the attempt to untangle this mess. How did we solve the problem with TSR's? Event driven operating systems. And how are we going to fix enterprise architectures? The same way! Just as Windows (built on the foundation of DOS) gave us a sane way to do multi-tasking, event driven architectures built on the foundation of our ridiculously coupled databases will make "enterprise architecture" more sane. Eventually, we'll make fundamental changes (just like Windows did when it added true premptive multi-tasking) to make things even better.

This is one of several places that Ruby on Rails nailed the right answer dead on. One of the obvious-in-hindsight decisions Rails encouraged/enforced was the "1 application, 1 database" style of application. If you need 2 applications to share knowledge, you do it with ActiveResource and messaging between applications. Once you assume that style of application, so much gets easier. You can stop worrying about the nasty high coupling between application's data access and start thinking about what individual applications need to do.

It's going to take a long time to fix this, though. While TSR's and DOS was a bit of a mess, it was a pretty small scale mess compared to what enterprise architecture looks like now. Given the fetishization of databases and the flawed assumptions that people apply to how to use them, it's going to take the rest of our lives to untangle this mess. There are movements afoot to rethink this within the database community (exemplified by books like Refactoring Databases by Scott Ambler and Pramod Sadalage. Just like with TSR's, we need to rethink Sidekick Oriented Architecture.

Saturday, September 06, 2008

Thanks for Flushing...er, Building


When things are automated, you just forget about them. And that's a good thing: you'd rather spend your time thinking about important things, like "is my design correct" or "should I be refactoring now". Developers who haven't embraced continuous integration yet spend way too much time doing something (builds) that are better left to automation. At the No Fluff, Just Stuff shows, one of the Sunday poll questions for the crowd is "How many are using continuous integration?" I'm always depressed to see that it's generally less than half the crowd. I can't think of any single practice that makes projects better than CI. Moving from building your project as a bunch of snowflakes (if you build using an IDE, what you build will be subtley different than what your neighbor builds, thus you aren't building the same thing: each build is like a snowflake) to a single, canonical build allows you to stop worrying about build problems. If it fails on the CI machine, it's broken, regardless of what happens on your machine. It frees you from the "midnight before the big demonstration, everyone's standing around Fred's machine because his is the only build that works" anti-pattern.

Having all that noise automated just lets you forget about it. As I was using the restroom in our Chicago office, I saw the perfect metaphor for this. Most of the newer buildings you enter now have auto-flush toilets, so that you don't have to touch any of the surfaces. It's become so common, in fact, that you forget that step in places that don't offer automatic flushing. In our office in Chicago, in the public restrooms, you see the "Thanks for flushing" sign on the wall. What a perfect metaphor! When it happens automatically, you can forget about it. When it doesn't, you have to remind people that it's important for the hygeine and smell of the environment to do the right thing.

If you haven't already, install auto-flushers for your project, in the form of continuous integration, and start thinking about more important things.