Too easy

When people sneer at a technology for being too easy to use, it’s worth trying out.

If the only criticism is that something is too easy or “OK for beginners” then maybe it’s a threat to people who invested a lot of work learning to do things the old way.

The problem with the “OK for beginners” put-down is that everyone is a beginner sometimes. Professionals are often beginners because they’re routinely trying out new things. And being easier for beginners doesn’t exclude the possibility of being easier for professionals too.

Sometimes we assume that harder must be better. I know I do. For example, when I first used Windows, it was so much easier than Unix that I assumed Unix must be better for reasons I couldn’t articulate. I had invested so much work learning to use the Unix command line, it must have been worth it. (There are indeed advantages to doing some things from the command line, but not the work I was doing at the time.)

There often are advantages to doing things the hard way, but something isn’t necessary better because it’s hard. The easiest tool to pick up may not be best tool for long-term use, but then again it might be.

Most of the time you want to add the easy tool to your toolbox, not take the old one out. Just because you can use specialized professional tools doesn’t mean that you always have to.

Related post: Don’t be a technical masochist

8 thoughts on “Too easy

  1. “Good for beginners” is indeed a completely invalid criticism. “Good for beginners, but lacks the features needed for more serious work” is not. Especially if the expectation is that the beginner will want to become expert, not just an occasional light user; say, EDA tools or other such system.

  2. Hide Complexity == Too Easy due to hidden complexity, possibly a good thing.
    Over Simplify == Too Easy due to closed choices, fixed menu, possible a bad thing.

    I would suggest that Windows vs Unix is a bit of both.

  3. Coming from mastery of “difficult thing x” gives undue incentive to dismiss “easy thing y”.
    However, from mastery in neither, one is given undue incentive to *choose* “easy thing y”.

    I guess what I’m trying to get at is that “difficulty” is often an orthogonal concept to “usefulness” (or “correctness”, or whatever). But the split of users *does not* necessarily reflect this orthogonality. For this reason, I think it’s valuable to consider learning the difficult things so at the very least you can be sure you weren’t dissuaded from the best choice for any reason other than it not being the best choice.

    ^ Haha, a bit rambly. But hopefully that added something. :)

  4. Echoing what Phil Do said about difficulty and value.

    I also wanted to add that ease and power tend to be the opposed forces and tend to prefer to something once the easy way, and many times the hard way. I tend to choose tools that are ‘hard’ and services and appliances that are easy.

    I tell my clients that Hard is just another way of saying Expensive and that Easy is another way of saying Ubiquitous. Building ubiquity into your product allows you to provide an approachable service from a place of focus. As more features are added, I find that it necessary to make the product ‘hard’ in order to allow its full feature set to be available to potential power users, integrators, and people building services on top of it.

  5. One problem with easy software is that it is normally limited; it assumes (good?) defaults, but eventually (in most cases) you are going to want to get past those. Then you have to learn an entirely new system, and might as well have not learned the simple one.

Comments are closed.