Easy to Use

I'm working in multiple tools and languages lately. It set me to thinking about what makes one better or worse than another. About the same time, I see a lot of mentions of yak-shaving hassles and OS reboots on twitter. I hear a lot of complaints about one feature or another of an ide, editor, or operating system and how they impede programmers from making software.

We advise people to stop measuring "agility" in agile orgs and try measuring whether you have a better flow of useful, high-quality software. In the same vein perhaps we should measure tools by whether they get things done rather than by counting features and corporate supporters. Are we getting more done?

A tool can be described as "productive" if it avoids adding obstruction to your workflow. If I want to do something, I am either allowed to do it easily (transparent tools) or I am impeded from doing it (unproductive tools). If I have to switch languages and contexts several times (as with java environments) then I'm impeded. If I can simply do what I wish (as with most python environments) then I'm productive.

This goes with cognitive load as well. How much do I need to know and hold in my head at one time in order to successfully navigate a complex system? The less I have to carry around implicitly in my head, the more I can focus on what I want to do. A counter example would be editing XML for an ORM, and then coding C# in a multi-tier architecture of classes, then XHTML for a web page, and then back to C# code for custom tags, and then a dive into javascript and some CSS changes to make it look nice ... adding a simple text field to an application may involve considerable impediment and travel between files, even if it is a "simple" store-and-report field.

As regard tools, the more quickly I can put ideas from my head into the code (ie. refactoring tools in Eclipse or Resharper) the more productive the tools are. The more the tools cause me to go somewhere else or type more or navigate mouse-and-menu, the less productive it feels. The more I have to switch between editors and languages to do a single job, the less productive it feels. Odd that I consider Java to be less productive than some other languages, and consider eclipse to be a highly productive environment. I guess it grew where it was needed.

The same idea goes with code. How much of it do I have to read (or reverse-engineer) in order to know what it is doing and whether I'm in the correct place to make a change? I've certainly dealt with code that gets in its own way until I am not sure whether I am even in the right place to make a change. By having temporal coupling, tuple madness, poor decomposition (no "centers"), or detail-heavy control routines, the code impedes my navigation. I want to know where to go to make a change. I want to get in and out quickly without any severe misunderstandings. I want to be productive. Good code allows me. Poor code impedes me.

I am debugging a tool. It has oblique error messages, so I have to dive into the code to reverse-engineer the issue. The error messages are non-specific so I have to modify them them and re-run the code so that I can see and correct the problem. The more specific the error message, the less I have to do to get my work done. The more oblique and detail-free, the more yak-shaving research I have to do.

That being said, I do understand that a mix of skills is necessary at this point in time. I think that (X)HTML and templating languages and CSS are perfectly good skills and highly necessary. I am just pointing out that the mix can make it harder to do web development tasks than some other non-web programming tasks, and that the toolkits are not to a point where simple things are truly simple. Likewise, I appreciate the advances in ORMs while noting the additional cognitive load involved. Sometimes it is easier to simply write a gateway object that interacts with good ol' SQL.

Now I understand why Google's search page is so brilliant as a consumer product. There is nothing I have to learn before I can use it. It gives me a clear message about my mistakes ("did you mean weird science?"). It provides me the minimal impediment. Likewise, I see how a lot of other web apps have failed. They crowd the space with many controls that obscure the few controls of interest, they provide little useful information in the error messages, they require too much yak-shaving (multi-page nonoptional wizard madness), they have funky implicit prerequisite structures that make one back out of a task and restart from a new initial state.

Especially as regards consumer-facing software, less is really more, and we should learn how to maximize the amount of work not done by users. Does it really take a four-page registration, a memorized secure password, and/or waiting through a flash greeting page to view "publically available" documents on your web page? How hard is it to opt out of a mailing or cancel service? How many forms and navigation pages does it take to extract some value from the web app you're building?

One final note: tools like vim and emacs *become* pretty transparent when you've been trained to them (as are Eclipse, NetBeans, and Resharper for VS.NET). You end up memorizing keystrokes, techniques, and tactics. You build up a library of magic tricks. These tools are transparent to experts in their use while being a pain for novices to pick up. They move from impediment to transparency over time.