The Artima Developer Community
Sponsored Link

Musings on Language and Design
Why it's better to be lazy
by Jeremy Meyer
June 8, 2008
Summary
Our parents were wrong when they told us not to be lazy. Laziness is a vital characteristic for success, and something we should strive for.

Advertisement

Classifying People

I have had recent to remember those 4 great classifications of people. Intelligent, Stupid, Active and Lazy.

My father often used to tell me about these classifications which he attributed to the Duke of Wellington. I have since read articles which have attributed them originally to Buddha, or some Buddhist swami, but the most credible source seems to suggest that they are more likely to have come from Helmuth Karl Gernhard Graf von Moltke, a German Military leader and strategist. (see below).

Actually it doesn't matter where they come from, the important thing is that they are an excellent insight into how and why people do things. If you haven't come across them before, they are very simple.

Everyone can be loosely classified into 4 groups, which are permutations of either activeness or laziness and , intelligence or stupidity.

Intelligent Lazy people, as my father would explain, are everyone's favourite. They do things in a smart way in order to expend the least effort. They don't rush into things, taking that little bit of extra time to think and find the shortest, best path. They tend to make what they do repeatable so they don't have to go through it all again. These people usually make good leaders, and they are good to have on teams.

Intelligent Active people are useful, because they are smart, after all, but their intelligence can be slightly diluted or tempered by their activity. Where they don't have a perfect solution, they might act anyway, rather than sitting on their laurels, so useful people but not great leaders, and on a team, they can often put noses out of joint by acting too early and too fast.

Stupid Lazy people have their place too, they are easy to manage, they generally don't act on their own initiative too much and, given tasks that are not beyond them, they will perform in a predictable, consistent manner. Usually they won't cause any harm on teams. Wellington, liked these people as foot soldiers.

Stupid Active people are the dangerous ones. Their default behaviour is to act, and in the absence of skill or thought they can cause all types of trouble.

Anecdotal Evidence

Stupid Active people are definitely good for one thing, though, they make for great anecdotes! They are the exclusive recipients of the Darwin awards, after all. We all know one of two of these, I bet if you think about it right now, you can think of at least one person you work with who you could classify immediately as stupid and active.

My own most recent amusing experience happened whilst on the management team for a large migration project. The team's task was to migrate UML Modelling projects from one version of UML to another, using Borland's Eclipse modelling tool, Together. In SCRUM tradition we had a daily call with our offshore team who were working on a backlog of many hundreds of projects that needed to be migrated. The task was fairly simple. Run the automated import facility, sanity check the project, and make any additional necessary changes to the UML model by hand.

One of the team, let's call him "Fred", reported that his progress was blocked by strange behaviour in his migrated Eclipse project. Diagrams were disappearing and reappearing and something was wrong. I noticed from his screen capture that something was awry with his project icons. I asked him to show me the contents of his Eclipse .project file. It contained the line..

<nature>uml14.uml14_nature</nature>

This is the line in the project file that tells Eclipse what type of project it is, and it told me that his automated import had failed. Clearly it had aborted, unable to convert the project from one type to another, no doubt due to corrupted input. I asked him to clean up the original UML diagrams, and re-try the import.

The following day, Fred reported that his icons were correct, but the project behaviour was still wrong. When I quizzed him on his approach, he explained that he had in fact edited the .project file by hand and changed the line above to:

<nature>uml20.uml20_nature</nature>

He had done this, he explained, because he had understood from what I had said that that particular line in the .project file was the problem. After much suppressed mirth, I patiently and politely explained that when changing the meta-model of one project to that of another, there was a great deal of work to be done, which is why it was automated, and why there was an import menu option for it. Manually changing the value of the "nature" tag in the project file didn’t change the nature of the project any more than wearing a baseball cap makes you a baseball player. To my astonishment, Fred defended himself with great verve. He stressed that he had "used his skills" in the best way he knew, to try and solve the problem. He seemed quite put out that I hadn't applauded his initiative. Not only was he actively stupid in his attempt to solve a problem, he was actively stupid in his attempt to justify it! Since he was my responsibility, but not my hire, I couldn't take what would have been my preferred action, firing him on the spot.

Everybody can be Stupid

Before I go on, I should say that Fred might well have been pretty smart in many ways. It has been my experience that you can't apply these classifications to people in general. There must be a context. You might be smart and lazy in your work, but stupid and active in the kitchen. I would like to believe that I am a smart, lazy software developer, but I am a very stupid, active DIY'er. Ask any of my friends who have been party to my crazy projects. My pond building exercise (where I cast my own bricks with moulds I made myself). Or my spontaneous tandoori oven, built from roof tiles at a holiday house in France (we ate cold, semi-raw chicken at 11pm that night). I am sure people do tend towards certain behaviours in all of their undertakings, but I think it is dangerous to apply the classifications generally. It is also hard to work with people whom you honestly believe are stupid in all walks of life. I have faith that there is something, somewhere that Fred does well and with careful consideration, but it certainly doesn't involve working with software tools.

Safety Net for Lemmings

My experience with Fred got me to thinking that when we create frameworks and even languages, we always try to cater for people like him. Some language designers feel this is their responsibility. Sometimes this is kind of helpful, like private methods and properties in a language, for example. Sometimes, it can be overly paternalistic. The old checked exception / unchecked exception debate springs to mind. C++ doesn't enforce the catching of an exception, Java does (with recent compromised made by Runtime exceptions). The question is, can you really defend yourself against active stupidity? Should you really try to defend yourself against it? Isn't it orthogonal to the actual intention of the effort, and just a bit like building safety nets on cliffs in case lemmings want to throw themselves off? (This is a metaphor, for more about the lemming myth, see the links below.) I was reviewing some code that looked like this, the other day:
   public void doStuff (int value) {
      try {
          applyCalculation();
      } catch (Exception e) {
      }
   }

Ah, that old chestnut. A swallowed, unlogged, unreported exception. It was lucky that I picked it up in the code review. This is a fine example of active stupidity in programming. It is actually less work, (less typing, even), and smarter to write:

	public void doStuff (int value) throws Exception {
		applyCalculation();
	}

.. clearly, having checked exceptions in your language is no defence against a developer who is this active.

Should we try and drop all of these types of controls in language and architectures? Of course not, it is just that there is unlikely to be a linguistic construct or design approach which can prevent active stupidity without being so infuriating as to be almost unusable by someone whose approach is more lazy and intelligent. The acknowledgement of that should lead to a happy medium between choking restrictions and complete lack of structure.

If you try to enforce exception handling, there will always be those who find a work-around for the construct. If you create a Singleton connection factory class to ensure a single point of connection there will always be someone who tries to hack their own independent connection to the server. If you try and enforce static type checking and make, say, a type-safe collection, there will always be someone who will explicitly typecast their Objects before they add them to make the code compile.. and so on.

It's People who Write Programs

Ultimately, until technology moves on significantly, it is people who are using programming languages and frameworks. The smart, lazy ones will be looking to reuse what they can and to find neat, idiomatic ways of achieving functionality. The active stupid people will be looking to "use their skills" like Fred did. And get stuff done.. Somehow.

Training, documentation, teamwork, and feedback all help to make people smarter (if not less active) and that is where a great deal of effort needs to be applied.

Too rigorous an amount of control in a language or framework doesn't do as much good as everyone thinks. It can often just create huge time overheads, as in the extra syntactic fluff needed to typecast because of Java's static type checking for example.

Affordance

An architecture or a syntax should provide a good context for creating idioms. It should make writing idiomatic code feel right without feeling that you have to jump through hoops. There should be an inherent affordance of the right thing to do.

This puts a lot of faith in the user of the language/ framework or whatever, but there are very successful examples of this. Languages like Ruby and Python (and of course SmallTalk) which allow parametric polymorphism tend to be scary to Java developers, it is, after all, a bit unbridled and wild being able to send messages to any type, but hey, smart lazy people never seem to get into trouble with it.

Perhaps a bit of judicious application of the 4 types would give us an idea who we should be looking out for in our designs and make us realise that some people don't need protection and others just can't be protected.

Next week, why it is better to be rich than ugly.

What do you think? Should we consider the importance of peoples' personalities when designing? What is your favourite anecdote of a stupid, active developer?

I hope you enjoy classifying your collegues!

Resources

Bruce Eckel on The Checked Exception Debate:
Checked Exception

..and The Static Typing Debate:
Static Typing

Helmuth Karl Bernhard Graf von Moltke
Creators of the German Empire

The Lemming Mass Suicide Myth
The Lemming Myth

Talk Back!

Have an opinion? Readers have already posted 16 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Jeremy Meyer adds a new entry to his weblog, subscribe to his RSS feed.

About the Blogger

Jeremy has been designing and developing software for over 20 years, as well as teaching its mastery. He is fascinated by all aspects of architecture, design and development, the philosophical, the psychological and the aesthetic. He currently heads up the training division at hybris Software, a fast growing and very exciting eCommerce company.

This weblog entry is Copyright © 2008 Jeremy Meyer. All rights reserved.

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use