When I see people after they have read about SOA or attended a conference with SOA, there are a few ideas that seem to pop up repeatedly. I have even been guilty of using these ideas myself. These ideas were proven to be bad before SOA came around, and (some) SOA evangelists seem to think that SOA solved these problems. It did not. It just refused to learn from history. Some of these ideas work under some circumstances, but recent SOA-itis has caused them to be used in inappropriate contexts.

Barcelona I just returned from The ServerSide JavaSymposium Europe. Great conference, with interesting tracks and good opportunities to get to know people. The conference was in Barcelona, which was interesting, because hardly anyone (taxi drivers and waiters included) understand English here. It’s the first time where I’ve been a place where I am totally unable to communicate verbally with people around me. So it as a bit of an adventure. My only gripe about the location is the price of WiFi access in Spanish hotels.

Roger Sessions has just published “A Better Path to Enterprise Architectures”. His main point is that large, centralized, big-bang enterprise architecture efforts fail. I could not agree more. Sessions gives some good arguments for why you would want to deliver incrementally. He calls this approach SOA. This is a fairly common way of defining SOA - basically SOA is another name for incremental deliveries. If this is SOA, I don’t hate SOA at all.

Blessed synchronizity: From Jason Yip’s blog: Vendor’s Law: Organise people into roles corresponding to the tools that you want to sell to them. And today’s Dilbert:

In my previous post, I talked about how I feel SOA encourages rigid design. Of course, in some situations, you may not really have a choice. When creating Business-to-Business (B2B) integration, interfaces will naturally be much more rigid. There is no way around it, SOA or SOA-not. Ian Robinson recently published an article on Martin Fowler’s webpage titled Consumer-Driven Contracts: A Service Evolution Pattern. The article gives some very clever ideas of how to make the consumers drive the service definition instead of doing this on the provider side (this is related to Lean Software Development, by the way).

On JavaZone 2005, I talked about “Why I hate SOA”. I found it hard then, and I’ve still found it hard for a while to express this sentiment concisely. I think I’ve finally got it! One of the most common inefficiencies I discover in organizations is poorly designed boundaries. I find that people suffer when a boundary is too ridig, not when it is too loosely defined. Contractual interfaces create a “mine versus yours” mentality, where every problem beyond the boundary is not corrected, but instead wrapped in even more code.

This post is an analysis of the difference in philosophy between static and dynamic typed languages and the pragmatic ramifications of these philosophical differences. I will use Nil/Null/None-types as basis for the example. The Nil-value is used in OO programming languages to designated a non-assigned value. Any object reference can be nil, which gives it a special role. In effect, Nil is an instance of all types. This is a concept that can only be expressed in a language that supports multiple inheritance.

One of the blogs I enjoy reading is that of Jason Yip: You’d think with all my vide game experience that I’d be more prepared for this (excellent title!). He usually writes short and sweet posts that gets a point across in just a few sentences. Here are a few of my favorites: The method where people talk to each other and trust each other and build things incrementally and… (I’ll probably blog about this at some later time) The Goals, Questions, and Metrics of User Stories One adopted improvement per person per week What’s the matter with that person: On reacting sensibly to stressful situations (much longer than average) It’s a blog well worth subscribing to.

Aslak Hellesøy created the …. interesting tool Guatanamo. From the documentation: “Do you have problems maintaining high test coverage? All code is guilty until tested innocent. Send the untested code to Guantanamo!” (that is, delete it) I think this is a very interesting policy, and even though it is too extreme to ever be practical, it reveals an underlying principle: If code doesn’t have tests, it doesn’t have value. Chances are that it is rigid, poorly designed, and wrong.

I am planning to see if I can do some more work on test automation. I have discovered that I am pretty good at going into existing code bases and adding tests now. In order to practice, and to have something to demonstrate, I would like to find a deserving open source project that I could add some unit tests to. The design of the project doesn’t have to be good.