It is really interesting what is happening right now in the grid or cloud computing field: the biggest player in this field is Amazon.com, a retailer. You would have expected grid computing or cloud computing to be championed by a tech company, I personally would have thought that Sun would be pretty active in this field, at the time I believed this 3-year old announcement to be more a bit more than hot-air.

You could speculate that Google is not lifting the curtain on parts of its infrastructure for fear that it would undermine one of its competitive advantage: the ability so scale out almost effortlessly. You could speculate that the large traffic sites which use grids for strategic reasons will be reluctant to open up their architectures to the outside world to the degree that Amazon has done and to a certain extent I see their absence from this space as a the cost of keeping inner workings of your organization away from your competitors eyes. Amazon probably has gone thru the same stage where its proprietary architecture was one important differentiator between itself and its competitors, but it looks like it has gone beyond it, it has grown beyond . Probably as Google, eBay, Yahoo, Microsoft will mature they will also start opening parts of their infrastructure which are not creating a difference between their services.

But I still don’t understand why Sun’s is silent in this space. Part of its strategy to move towards open source would have been to move towards services at the same time (since your code doesn’t pay you need to make money from running services on this code). Support is one type of service, but I see grid computing as one service which is far more profitable to Sun.
Cloud computing comes with a pretty high entry barrier: you need know-how, operation teams, investments in hardware, etc… in order to run the large data-centers that are hosting this service. Sun could have tried to do that and in the article at the beginning of the post they seemed pretty determined to open up such an environment. Judging by the size of their investment in MySql you could say that Sun it committed to software. I don’t see hardware playing a big role in the future, but rather infrastructure. Once you solve the problems of scaling out the need for big iron boxes diminishes, however the infrastructure starts to matter a lot. The only thing that Sun seems to do is to sell various grid-solutions but not to host grids, I think they are missing out on a big piece of what will be demanded in the future IT landscape.

So how do I see Amazon’s grids doing in the future? I see them doing pretty well, for now the market for grid computing on a credit card (to quote Cameron Purdy) has only one seller, that is Amazon. Amazon will bank on the integration between small companies and its grid capabilities, integration which translates in in the number of VM images stored on EC2, on the different configurations that different hosts are using, etc… This integration is essentially an infrastructure lock-in and once Amazon has acquired these customers it is a safe bet that they will not migrate to its competitors (which are yet to appear) easily.

Later edit: I was thinking about using Amazon`s EC2 to host Facebook applications which start having operational problems because of becoming immensely popular (as illustrated on this post on Marc Andressen`s blog). It would probably make sense, but I didn`t dwell too much on it.

I was reading the Prefer Design Skills post on Martin Fowler’s bliki and I agree with most of its conclusions. He’s spot on on the need to prefer someone with design skills vs. someone with skills about a particular language.
Design skills carry a lower risk of becoming obsolete than the knowledge of a programming language, programming languages come and go, good design usually stays. So it would follow that when you bring design skills in house you bring in skills which depreciate slowly and this is beneficial.

Design skills are largely the outcome of some soft skills (good communication with the customer, easy understanding of a domain, maybe knowledge of a few domains, etc…) that are much needed by any developer. When you bring design skills in-house you also bring those soft skills in. These soft skills will translate in a more frictionless environment, better communication with the client, faster ramp-up on new projects for which the person with design skills has domain knowledge, etc…

Hiring a person can be viewed as an investment: you are investing the salary for the probation period, the relationships that this person will make (these relationships may included relationships with your customer).

Hiring a person comes with opportunity costs: you will probably have to refuse the same position to some other one.The opportunity costs of a hire are the skills of the person(s) which has/have been refused the position and the contribution that the refuse would make in the future, it is important to keep these costs down as well.

The opportunity costs of choosing a person with design skills vs one with language skills is largely the time it takes the design-skills person (I am getting tired of typing this denominator) to learn the language. I would trade this opportunity cost vs. the opportunity cost of hiring someone with no design skills because I feel so (sorry, I don’t have time to go into details).

Reading the above you will see a huge bias towards design skills vs. language skills in this post to the point of where you are probably wondering when should you hire a person with strong language skills (or who knows, maybe if you should hire such persons at all).
Staying in the same controlled thought-experiment environment I would add that positive bias towards a particular set of people tends to rise those people’s salaries, they become more expensive as the demand for them increases faster than their supply. It would follow that at one point the premium associated with design skills would become so large as to dwarf the benefits from employing people with design skills. At that point it would become economically sensible to hire language-skills people.
Another point would be that you could lower the opportunity cost of refusing a person with design skills by hiring a person with language skills which is motivated to sharpen his/her design skills. If you come across such a person the opportunity cost of hiring his/her would be the contribution made by the person with design skills while the person with language skills is still in the ramp-up period of sharpening his/her design skills. I would say that this opportunity cost would be more than offset by the relationship that you will develop with the person with strong language skills while mentoring, tutoring his/her.

And this is the last time you will read design skills in this post, I feel like I said it 500 times ;-).

P.S. I guess it shows that I love economics ;-).

I am testing a few things with my RSS feed, it will change the way it exposes the contents of this blog.

I hope it will not create much of a disruption.

I was reading this post on manageability.org which is hi-liting some of the problems with large projects in dynamic languages. I am not familiar with these problems, never having to code in a dynamic language on a large-scale project, but I am currently working on a large scale project in Java with many distributed teams and in such an environment it is crucial that the code created by different teams is put together fast and reliably. Putting the code from various sources together fast is necessary for efficient collaboration between teams.

Probably the number one problem of distributed teams working on the same project is to make sure that the code doesn’t contain references to methods which don’t exist or which have changed. Statically-typed languages solve this problem by their own definition at compile time. Dynamically-typed languages probably have some solutions to this problem (I heard some people documenting the Ruby code that they write), but the biggest drawback of them is that this type of solutions are human-powered and not automated, an automated solution would be something similar to a compiler inspecting your code for invalid method calls. I would say that the solving code-conflicts that arise in distributed teams are more expensive in dynamic languages than in static languages, therefore when choosing a dynamic language you should probably stay away from coding in a distributed development environment (*).

One problem that I see with Ruby and all those elegant languages is that they are not very expressive to a large audience. They encourage brevity, but I find that they encourage it at the expense of readability and this narrows their audience (this is why I find it unlikely that Ruby will break out of a small elite). A developer working on an application needs to understand pretty fast what a particular method does rather than marvel at the “beauty” of that particular piece of code. I find that the information stored in Ruby code is harder to extract than the same information stored in Java code. It is “beautiful” (**), but also inefficient and it is more expensive to work with it.

I would say that the biggest challenge using dynamic languages revolves around collaboration and communication. Statically-typed languages put a smaller cost on communicating thru code, dynamic languages can achieve the same thru some external mechanism. While dynamic languages have more features, this freedom comes at the expense of collaboration. Evidence would seem to make this supposition true, most development in dynamic languages happens in small teams concentrated locally where the needs for communication are small.

* All the above being said I remember Martin Fowler talking about agile projects coded by distributed teams which did very well. He didn’t mention what language these teams are using, but given the fact that ThoughtWorks seems to favor Ruby I would assume that these distributed teams were using Ruby as well. It would be interesting to see the steps taken by them in order to be able to handle these communication problems.

** I personally find it brain-dead to talk about the “beauty” of code because this is not the purpose for which code is written. A statue should be beautiful because this is its purpose, to be enjoyed by who watches it, a piece of code’s purpose is to work as it is supposed to.

Later Edit: The communication and collaboration costs of dynamic languages will define the population of developers that use them and their usage within that population. I would not be too surprised is most of Ruby and Groovy usage will be restricted to small scripts which do not require a lot of collaboration while a small niche of very productive teams will be able to use them on a large scale.

If you are to read most of what is published today about the Java platform it seems that the future of Java doesn’t look pretty good at the moment as it keeps losing battle after battle with the movement behind dynamic languages such as Ruby and PHP. At the same time improvements to the language which could give it some boost seem to be badly implemented, most people beeing unhappy with the implementation of generics and the proposed closure enhancement looking pretty horrific.

You have to wonder what will happen to Java in the future. Will it disappear and turn into a dinosaur that could not adapt to a changing IT environment or it will manage to survive the problems that it has at the time? One good look at the Java language would have to consider both the language itself and the libraries/frameworks built under it, the contributors to the language, both contributors to the language features and to its libraries/frameworks, etc… as well as the users of the language and its libraries, i.e. the developers that create Java applications.

The different types of contributors to the Java language. I would start by looking at the contributors and I would split them in 2 camps: corporate contributors and non-corporate contributors (*). Looking at the chief contributions these 2 types of contributors make to the Java platform I would say that the corporate contributors are mostly active contributing libraries and frameworks and that the non corporate contributors are contributing Java language variants such as Groovy and Scala (**). The split between contributors seems to mirror the split between the language itself and the libraries/frameworks being built under it, this is an important point.

It is important to look at the motivations of each contributor type for contributing to the Java platform: the corporate entities are mostly contributing libraries and frameworks that target specific problems with a wide audience while the non-corporate entities typically target problems with small audiences, such as languages. The size of the entities involved in a particular task is usually a good indicator of its audience and of the need for coordination (the bigger the number of entities, the bigger the need for coordination).
Corporate entities are more effective in projects where a certain amount of discipline and coordination is required (such as when defining the WS-* specs), while non-corporate entities are more effective in projects which do not require a large amount of coordination. The need for coordination between corporate entities is primarily driven by the number of these entities and the fact that these entities have different, sometimes competing, interests to which a common denominator has to be found.
Opposite to the need of coordination you would find most entities that created the languages currently running on the Java platform: These languages are initiated by individuals and are maintained by a single team that is usually pretty small.

One important thing about the contribution of corporate entities to the Java language in terms of libraries/frameworks is that these corporate entities need these huge investments in libraries/frameworks to be relevant in the future. Backward compatibility is very much needed for them in order to provide the stability required for continuing to make these contributions, this is very important to consider when thinking about truncating Java (see small section below) and when making language changes.

The mushrooming of JVM languages (***). You would expect that once the JRE got modified to allow easier access to different languages on the Java platform that the number of Java variants will grow very large, to the point of becoming unmanageable. This has not happened so far and if I were to identify the reasons for this I would first say that 1) there is an entry barrier for creating a language, you need to design it well and 2) the need to keep relevant investments made when committing to a particular language. The small number of languages used on the Java platform, in sharp contrast to the number of Lisp variants, is due to the fact that when a entity adopts a such a language it will make a commitment to use it in order to keep development costs down (you don’t want your web development shop to work 10 different languages, each needing a guru). The need to keep development costs down, which doesn’t exist in Lisp’s world because Lisp is used by academia rather than by everyday coders, put a ceiling over the number of languages running on the Java platform. I would expect this pressure on the number of languages running on the Java platform to exist in the future, new JVM languages will start being used only if they truly offer gains(****).

Open sourcing Java. Just like the mushrooming of Java languages the mushrooming of Java-like languages which branch out of the main Java language maintained by Sun didn’t happen (looking at the hundreds of Linux variants you would have thought that it should happen). I think that this is due to the exactly same thing that prevented the mushrooming of JVM languages - the commitment that using a language entails.

Truncating Java. The JRE got too big and even with today’s networks it is still a pain to download and install it. Split it up in OSGi bundles and spin them off the runtime (with Java AWT and Swing being the first victims). Keep in the runtime only what is absolutely necessary for the current enterprise libraries to work well (the collections library, threads, etc…).

Competition from Ruby. Ruby appears as a serious contender to Java, supposedly gaining market stare and mind-share. I don’t think that this will last long primarily because Ruby will not have resources for re-creating the current Java libraries. I also think that re-creating Java’s libraries in a different language is a waste of time. My opinion is that it is beneficial to learn Ruby in order to use JRuby and tap into the vast libraries currently available on the Java platform.

My opinion on Java’s present and future. I think that the current split in contribution to the Java platform (corporate contributors generating libraries, frameworks, products, etc… and the non-corporate contributors creating languages) is correct. Let each camp go forward in its own way, the corporate entities will continue to produce the specs, libraries and frameworks that we all use and that we all need to be relevant in the future while the non-corporate entities will work on creating new languages from which to call those libraries. There will not be a mushrooming of languages because the costs associated with using a language will keep the number of languages down. There will be some healthy competition from various languages that attain buzzword-status, but it will not last for long.
This would conclude my post. I admit that its subject (Java’s present and future) is very broad and covering it in one blog post is very hard but I have these opinions that I want to share with the world.

* By non-corporate entities I mean most small cohesive groups that grow around Java such as the groups maintaining Groovy, Scala, etc… By corporate entities I mean both large corporations involved in various specs (such as IBM, BEA, Oracle, etc…) and small corporations such as Spring Source or Red Hat. Also, the contribution of a corporate entity to the Java platform is not restricted to the contribution that entity makes in the open-source space, but it means all the code that entity has created in the Java platform, closed source as well. I know this definition borders somewhat on using the language rather than contributing to it, but I will keep it this way.

** I know that Java languages are also contributed by corporate entities with JRuby being contributed by Sun being one such example (Sun actually brought JRuby under its umbrella, JRuby being started by a non-corporate entity).

*** By JVM languages I mean languages different from Java that run on the JVM such as Grrovy, Scala, JRuby, etc…

**** Interestingly enough, Java platform languages would be a pretty good case of study for word-of-mouth advertising: some guy created Scala, another guy tried it and blogged about it, few more did the same, some other guy requested some features, etc…, before you know Scala is slowly being shoved into the spotlight.

“For cooking instruction please go to so-and-so.com”.
Far out. I wanted to cook some couscous and when I was looking on the package for the time I had to boil it and for how much water to add I came across “For cooking instruction please go to http://phoeniciaproducts.com“.

Guys, I wouldn’t bank on people going on the web for cooking instructions, at least not now and not here in North America. I would definitely not bank on people searching your poorly-designed site in order to find out how to cook the food they bought from you while the water is boiling in the pan. I would bank on people reading the food package for this.

Cheers!

Andrew Odlyzko, the head of University of Minnesota’s Digital Technology Center has this interesting paper on Net Neutrality. While I don’t buy all of its arguments, especially the ones on financial markets, Andrew puts an interesting perspective on the Net Neutrality debate: a brief history of price discrimination in history and how once Net Neutrality achieved Google will have a lot of incentives in engaging in price discrimination itself in a different domain.

One interesting point is that legislation relating to price discrimination in one domain or another appears because it is demanded by the people rather than because it is demanded by some corporation or another.

… is probably WebLogic Server 10’s management console because the moment you encounter it you feel like leaving enterprise Java completely. After using it for a while the phrase “bloated piece of garbage” comes to my mind upon seeing its blue colors.

I find that WL10’s console fails pretty badly the test of diversity: an application server would ideally need a console that can accommodate everybody from a developer testing its code to an operations guy managing it in production mode. The number of roles in IT is increasing and a product that is being used by various people in various roles needs to adapt to each of these roles. Sadly, WL10 doesn’t do it, it assumes that you need all the time all the bloat that it can provide.
You would expect WL10 to find a way to delegate handling the complexity of running servers to its users (such as the possibility of creating profiles that would allow someone to run common tasks more easily), but this doesn’t happen. I think this delegation is necessary in order to make WL10 more easy to work with for the growing number of IT roles that are using it.

The funniest thing that I see when I start up a server is the below screenshot detailing the settings for a particular WL10 server:

The red lines display the items I have never, or very rarely, interacted with. Why do I need to click on Federation Services for testing one of my EJBs? The number of unnecessary links that WL10’s console throws at you is probably somewhere around 80% of its “real-estate”. “Real-estate” being wasted away.
BEA should find a way to make its customers use its features (which I assume are quite useful) in a more efficient way. Throwing a ton of buttons, links, features at an unsuspecting user is not the way to go about it.