CodeBetter

I've been doing some hunting to follow up on my previous posting regarding web service naming conventions and standards.  The pickings are slim.  Thomas Erl, a Canadian SOA expert and author, mentions some SOA naming conventions in an article he wrote for Oracle entitled Standardizing Service Endpoints. 

He prescribes a practical approach, naming services based on the utility (verb), entity (noun) or task/function (verb-noun -- do something to something), dependant on the scope and context of the service.  He also warns about ensuring that operations within the service reflect appropriately the scope of the service, and to eliminate redundancy in operation names.

From the article:

• The utility-centric context is found in application services involving operations that encapsulate cross-cutting functions, such as event logging, exception handling, or notification. These reusable services need to be labeled according to a specific processing context, agnostic in terms of any particular solution environment. For example, a utility service might be named Notify.
• An entity-centric context is established in a business service that represents a specific business entity, such as an invoice or a purchase order. The labeling of entity-centric business services is often predetermined by the entity name. For example, a service may simply be named Invoice or Customer.
• Task-centric contexts are required for services modeled to encapsulate process logic. In this case, the thread that ties together the grouped operations is a specific activity being automated by the service logic. Therefore, the use of verbs in service names is common. For example, a task-centric service may be called GetProfile or ProfileRetrieval, if that accurately represents the task's scope.

As with service names, labeling individual service operations is also a process that should be subject to standards and guidelines and for which there are already several best practices.

For example, the naming of the service itself ought to influence how the individual operations are labeled. Because a good service name will already clearly establish a meaning and a context, operation names should be streamlined to avoid the use of redundant wording. Take an operation that retrieves invoice history data for a service named Invoice. This operation does not need to be labeled GetInvoiceHistory, because the invoice context is already established by the service name. GetHistory would be sufficient.

Thomas really helped us move forward with our SOA initiative at CISTI both with a workshop to bootstrap our process, and through his books. 

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.

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 nearly 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 is currently a principal consultant for Borland Software in their modelling and design space.

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

One of the new features of C# 3.0 is the var keyword, which can be used to implicitly declare a variable’s type. For example, instead of declaring the type, you can just write var instead, and the compiler will figure out what type name should be from the value assigned to it:

1.// A variable explicitly declared as a certain type.

2.string name = "Richard";

3. 

4.// A variable implicitly declared as the type being assigned to it.

5.var name = "Richard";

Note that a var isn’t a variant, so it’s quite different from say, a var in javascript. C# vars are strongly typed, so you can’t re-assign them with values of different types:

1.var name = "Richard"

2.name = 62; // error, can't assign an int to a string

Vars were introduced to support the use of anonymous types, which don’t have type names. For example:

1.var me = { Name: "Richard", Age: 22 };

But there’s nothing to stop you from using vars with regular types. In a recent article on codinghorror.com, Jeff Atwood recommends using vars “whenever and wherever it makes [your] code more concise”. Guessing from his examples, this means everywhere you possibly can.

The logic behind this is that it improves your code by eliminating the redundancy of having to write type names twice — once for the variable declaration, and again for a constructor.

There’s always a tradeoff between verbosity and conciseness, but I have an awfully hard time defending the unnecessarily verbose way objects were typically declared in C# and Java.

1.BufferedReader br = new BufferedReader (new FileReader(name));

Who came up with this stuff?

Is there really any doubt what type of the variable br is? Does it help anyone, ever, to require another BufferedReader on the front of that line? This has bothered me for years, but it was an itch I just couldn’t scratch. Until now.

I don’t think he’s right on this one — my initial reaction is that using var everywhere demonstrates laziness by the programmer. And I don’t mean the good sort of laziness which works smarter, not harder, but the bad sort, which can’t be bothered writing proper variable declarations.

Jeff is right though – writing the type name twice does seem a little excessive. However, as Nicholas Paldino notes, the correct way to eliminate this redundancy would be to make the type name on the right hand-side optional, not the left:

While I agree with you that redundancy is not a good thing, the better way to solve this issue would have been to do something like the following:

1.MyObject m = new();

Or if you are passing parameters:

1.Person p = new("FirstName", "LastName");

Where in the creation of a new object, the compiler infers the type from the left-hand side, and not the right.

Microsoft’s C# language reference page for var also warns about the consequences of using var everywhere.

Overuse of var can make source code less readable for others. It is recommended to use var only when it is necessary, that is, when the variable will be used to store an anonymous type or a collection of anonymous types.

In the following example, the balance variable could now theoretically contain an Int32, Int64, Single (float), Double, Decimal, or even a ‘Balance’ object instance, depending on how the GetBalance() method works.

1.var balance = account.GetBalance();

This is rather confusing. Plus, unless you explicitly down cast, vars are always the concrete type being constructed. Let’s go back to Jeff’s BufferedReader example, of which he asks, “is there really any doubt what type of the variable br is?”

1.BufferedReader br = new BufferedReader (new FileReader(name));

Actually, yes there is, because polymorphism is used quite extensively in .NET’s IO libraries. The fact that br is being implemented with a BufferedReader is most likely irrelevant. All we need is something that satisfies a Reader base class contract. So br might actually look like this:

1.Reader br = new BufferedReader (new FileReader(name));

Just because a language allows you to do something, doesn’t mean it’s a good idea to do so. Sometimes new features adapt well to solving problems they weren’t designed for, but this is not one of those situations. Stick to using vars for what they were designed for!

June 21st, 2008 | 40 Comments

Instead of hammering on the differences between
dynamically and statically typed languages, we should
instead strive for a peaceful integration of static and dynamic
aspect in the same language. Static typing where possible, dynamic
typing when needed!