There are unknown consequences for any deep interventionist economic policy. Anybody who says so it’s either a fool or badly naive. But worse of all, intervention of this kind defeats the system as we know it, where the fittest survive.

Without intervention this crisis would have been a chance for those without debt to compete, i.e. the very poor.  All that we will see is further foreign investment from large sovereign funds, and that hardly benefits the poorest nations in the World.  I am very disappointed by our politicians lack of pro-activity and foresight.

We live in a culture that encourages risk, and hence competition and growth. But now we have simply wiped out the consequences of failure. The failed specimens survive, unlike what Darwin taught us …

Sometimes you are part of the folks in the plane for whom the system does not work. The crew will normally start rebooting your seat, then the section, and then the whole plane. I guess they do so in hopes that the operating system running the streaming adheres to the same random rules as the one running on their desktop.

In case of an incident with the entertainment system, i.e. in every single flight, the crew keeps apologizing about not being able to fix the problem and continue performing reboots left and right. Reboots are seldom able to address the problem, and the only thing reboots achieve is general frustration, both from those without video, but mostly from those with video who see their programs shut down. Eventually, the crew settles down to multicasting a few movies.

Virgin Atlantic even has the courage to advertise Virgin Media Broadband and TV packages on a commercial playing before the movie. Enjoy this cool entertainment system (that does not work) at home just like you do in the plane. I am no marketing guru, but that sounds to me like a dumb ass campaign.

I’ve seen a few times a linux boot-up sequence on Virgin, and I’d be surprised if BA was not also using Linux. Most likely, they are both using VideoLAN against one or multiple streaming servers with network attached storage. For whatever reason, it’s the connectivity that fails, and the individual Linux workstations that fail to connect to the streaming server, or for the streaming server to be able to read the files from storage.

The reason to use attached storage is two-fold: cheaper, reliable and easier to update. But, guess what, wired networks don’t seem to be reliable on a plane (probably because of the high-frequency power lines). So here’s my advice folks: avoid the network (single point of failure). Here’s how.

Virgin Atlantic has around 100 movies on inventory, plus TV series, CDs and radio programs. I’d bet their total inventory at any given point in time is between 250Gb and 500Gb. Maybe the solution to use shared storage made sense years ago cost-wise, but today the cost per Gb has fallen so much that internal disk storage could make more sense. Specially since there are no availability requirements (if it fails, a simple swap fixes the issue).

They could get a 1Tb disk per seat and image (push on the ground) all disks with the OS, the video player plus and the full media library. Re-imaging will take a few hours, but the inventory only gets fully updated every 2 to 3 months. Every seat would become an autonomous and reliable processing unit with its own storage. And in case of failure, it would only cost $100 to swap disk and reboot one seat, something the crew could do in-flight. No apologies, no pissed off customers, no compensation.

So, guys, go and implement it, so that I don’t have to watch the beginning of The Oxford Murders from Alex de la Iglesia three times on my next flight.

As background, I have recently been recruiting to backfil Remy, Yahoo!’s Chief Architect for Europe [and no, I am not looking any further]. It has proved to be a hell of a task. My mailbox and voicemail have been flooded with messages from agents and candidates. A pile of resumes to go through.

Most resumes are immediate rejects. Absolutely zero experience in online technologies. Do you apply for Yahoo! if you don’t have a clue about even building a site? WTF!??? And, err, where is your blog, buddy? This is not just any job.

Anyway, moving on to interviews. I called in a few guys with very solid resumes. Outstanding resumes actually. Tons of experience. Lots of technology expertise, masses of troops, managing huge budgets. Right, bring them in, I say.

On the interviews (so that you know) I don’t look at the resumes, ever. I could not care less, because you are allegedly supposed to be able to synthesize and I can read. So, expect to work hard at the interview. Rather, I’d love to see you design flickr, or Answers, or tell me how the frontpage could/would/should work, or, for fun, how you would liberalize the water supply system in the UK. I bring engineers on the room to discuss. They need your help, guidance, steering for making choices. Help them!

All I want to learn is that you can think beyond a Powerpoint and a bunch of theoretical ivory-tower diagrams. And you know, most often, candidates can’t. The large majority of candidates when going through the exercises just put a few boxes up and don’t actually get into what are the hard bits. And when challenged to think through them, they fail. I admit you might not know how to build our frontpage, but at least you should be able to appreciate the complexities during an interview.

The interesting thing is that all these candidates that fail have a common trait. They are the enterprisey architects (a few exceptions exist, like my good ol’ friend Jeremy who is truly an enterprise architect). Enterprisey architects come with certifications, waving their TOGAF and Zachman willies. They operate so high-level that they ain’t got a fucking clue.

Enterprisey architects make the argument that architects don’t need to actually know the details (I don’t code, they say). First, there is a hell of a difference between coding and designing systems and you seem not to be able to design systems. Secondly I honestly think there is something seriously wrong with anybody who wants to be a technology geek and does not like programming languages per se. It’s like being a butcher and not liking meat. I’ll tell you what: if you are not obsessed by [technology|volumes], you are not a [technology|civil] architect.

An enterprise architect is the architect that looks at solving problems across the enterprise, not the department, or the business units, to leverage the synergies and lead towards the future-state architecture. [Don’t look this up, I just made this up].

An enterprisey architect is the architect that wants to be an enterprise architect but fails to engage with his customers, because he’s not capable of being detailed enough (business strategy detail, functional domain detail, applications and technology detail, and infrastructure detail).

And as I keep telling my guys, (enterprise) architecture is not about technology, it’s about people. You are expected to know the technology, mind you, but there are usually much more specialized engineers who need your steering for making choices (if they aren’t such experts in your organization, you should start by building your team), so that you can find the detail that is relevant. You are supposed to understand the bigger picture, and lead folks into doing the right choices, so that you are not only doing things right, but also doing the right things. Enterprise architects use their social networks to make technology changes happen.

Again, it’s not about technology, it’s about people. But you know your technologies, right?

smartphone centric OSes are designed to address the limitations of the constrained mobile environment, while at the same time delivering a rich user experience. typical constraints range from input methods, battery and connectivity. let’s be clear, these are good phone OSe,s, and they make good phones. but interestingly, these are constraints that have started to go away, and are becoming largely irrelevant, if not already irrelevant.

mobile network connectivity now offers full TCP/IP stacks on always-connected phones under flat fee transfer rates. battery life on most new phones allows such stack to be always on without significantly affecting the batter life, and input devices such as the iPhone demonstrate that the paradigm can be changed for the best.

in contrast, desktop centric mobile OSes are not really designed for mobile environments, and mobile is just an add-on. where the smartphone centric OSes need to impose API limitations, the desktop centric OSes don’t impose almost any. where the smartphone centric OSes excel as phones, the desktop centric OSes tend to lack important features (the iPhone is a good computer but a really bad phone).

and the question really for developers starting now a new application is whether to develop for such phone-focused OSes, given the large market share, and hoping that they will be enhanced sometime in the future to become full OSes, or whether to go for desktop centric OSes, with currently a smaller market share, and hoping that the mobile features on the them are sufficient. in other words, what’s more likely to happen, a desktop centric mobile OS being enhanced to become better phones, or a smartphone centric OS being enhanced to become a better desktop?

the answer to this leaves within the OSes themselves. today, the iPhone is an excellent mobile computer based on the OS X, but it’s a really bad phone. however, the mach/bsd kernel, the quartz framework and the cocoa framework should make it relatively easy to add GPRS and UMTS to an iPhone. and possibly the only reason it’s not there is purely commercial, based on the current distribution deal with AT&T.

in contrast, you can’t make a good desktop OS out of the smartphone centric OSes. they are simply crippled. i find it surprising to see how analysts overrate the symbian os. technically, symbian is a really unattractive and unproductive development platform to work with. commercially, it’s a fragmented market with three competing and somehow incompatible platform variants: nokia’s s60, sony-ericsson’s uiq, and ntt docomo’s moap.

from a technical standpoint, symbian has its own memory management and exception handling mechanisms which lead to a crippled and unfriendly C++-ish variant. symbian support for string handling is as bad as it gets, and even php does a better job! finally, writing complex interaction paradigms and network access is daunting: multi-threaded applications for symbian requires rocket scientists. and finally, and most importantly, the development environment is simply non-existent, mostly because of the custom C++ memory management and complex deployment process.

very sadly, java does not make a much better symbian. although language and tool support is excellent, the lack of uniformity on the platform itself, with MIDP 1.0 and 2.0, being implemented to different degrees by different vendors and by models, has resulted in tens of different APIs supported by some but not all phone models. it’s really hard and time-consuming to develop for java applications for symbian. either you create multiple variants of your application, or you cut down to the least common denominator. neither option is attractive from a developer standpoint.

windows ce suffers similar problems to symbian. the programming model is overly complex and based on the highly developer unfriendly win32 api. alike java, the .net compact framework has not been consistently adapted, so one ends up with multiple binary targets, that require separate code, debugging, testing, distribution and installation. a nightmare from a developer’s perspective. on the plus side, windows ce development environment is superb, including remote debugging abilities on the device itself. but overall, i discount windows ce as a no-go platform.

this really cuts it down to desktop centric OSes being a better choice for development going forward. that’s really between OS X and Linux. and i am picking OS X and the iPhone. here’s why.

as with anything linux, mobile linux is really many many things. different vendors have implemented things differently and are providing different stacks. some offer Qtopia, from Trolltech, some offer Gnome. then you have android, openzaurus, openmoko, … no one phone has a significant market penetration, and to develop for linux really requires multiple binary targets and API abstraction layers. again, it’s making things more complex than it ought to be.

in terms of kernel and integrated development environment, OS X is a much better platform. it’s a highly productive environment. but it’s proprietary to apple. which is good and bad. it’s good since you know what hardware and software you need to support. it’s bad since you are locked in, including for distribution.

but here comes the twist. developing a cocoa-based application for the iPhone is extremely easy, and given that Linux and OS X (mach/BSD) share so much in common, moving an iPhone application to a linux variant would not be any harder than moving between Gnome and Qt. good OO design should make it relatively easy.

in summary, iPhones features a robust and rich OS, OS X, a highly productive development environment, an aggressive market share growth, and lots of similarities with Linux. these are all good reasons to me to pick the iPhone as the target mobile platform of the future. i am not fully discounting linux however. the current issues with lack of significant market penetration could be overturn, specially in asia, and particularly in china.

That’s why facebook is popular - it’s fun, it’s about image, it’s about entertainment.

And now, to prove it, a nice chart for the breakout of Facebook applications.

I gotta love it.

http://www.google.com/virgle/index.html

Of course you could build web applications using either JSPs or one of the hundreds of web application frameworks available for Java. And a lot of leading players are doing just this. But contrary to some “enterprise” thinking, Java is by no stretch of imagination the leading language for web development.

The number of available web frameworks for Java is an indication of a ground where a problem exists that has not been addressed in any fully satisfactory way, yet. And I believe the key problem is productivity: Java is, still, not a productive platform for development, whereas it is probably the best available platform for production. And the thing is that although there is a very large, mature and globally distributed pool of Java server-side developers, Java is still hard to develop for because it is not a productive platform for this “glue”.

A clue as of why it is not productive comes from analyzing the prime language users: the frontened web developers. It is actually really hard to find frontend web developers that want to use JSPs or any Java web framework. They rather use PHP, or Python, or Ruby, or Perl.

What all the P- scripting languages share in common is the low specs required to get started, the easiness itself to get started and hack something together, and most importantly that it only takes a single browser refresh to check any change and push the change to a production server. Sure, this is not a good practice (pushing to production), but it’s something that for 99% of sites out there, it just works and it’s good enough.

Java makes deployment hard. Starting a JVM takes seconds, refreshing a JSP takes seconds, changing classpaths, etc. require a restart or reload. Hardly productive. And the thing is, even though Java is more robust, better structured, and enforces better development practices, 99% of the sites out there just don’t need this level of “enterprise” features. And I am not the only one saying so. Even Billy Newport, one of the lead architects behind WebSphere Application Server, and the Chief Architect behind WebSphere XD, has expressed this very same thought, that Java needs to figure out how to become as productive as PHP.

The productivity derived from the scripting language in those 99% of web sites out there is what makes Java unpopular for the remaining 1%. Java has to grow up in the web dev area. Ideally, one would like to take the best of both worlds: the robustness and performance of a JVM, and the productivity of the P-languages.

In my yearly review of the state-of-the-art, I am starting to think that this change to make Java more productive is finally starting to happen in 2008. First was the advent last year of the scripting languages becoming a target of the JVM, such as Jython, JRuby, PHP, Groovy, Scala, etc. made it possible to benefit from the JVM robustness. But still one had to suffer the JVM weight inflicted by Java (the language) centric development practices.

It’s really only been over the last 6 months when we have seen a number of open source and closed-source projects taking on the task of bridging the scripting and JVM world together for web development. A couple of the web frameworks that I am interested in researching more about and that look rather promising to me are Project Zero, and liftweb.

In summary, I really think we may be looking at 2008 as the year when Java finally graduated in the web dev frontend area. I certainly hope so. But only time will really tell.

Disclaimer: this is not, by any stretch of imagination, Yahoo!’s official view. Don’t try to read too much into this posting. For those that know me well enough, you’ll know that I have been looking into application frameworks, web and others, since 2000.

It is attractive to bet on emerging technologies. They are sexy, cool, promising high productivity gains, and in a way, good technologies are disruptive, not only to the technology landscape, but to the business landscape, since they change what can be achieved with technology.

And so, we feel inclined to risk and pick emerging technologies, without perhaps taking the time and consciously analyze and understand the impact. To list a few things:

• How many developers can I find with the required skills to support this technology? Where are they located? Are those locations where I can attract and retain talent?
• How secure and proven is the technology? Is there a good track record of fixing security bugs in very short time-frames?
• How complex is it to deploy this technology? How stable is it and what is the monitoring and analytics required to operate it?
• How long would it take to migrate everybody in my company/group/division/org from the “old” stuff to this “new” stuff? Does it pay off?
• How long would it take to migrate my project from this “new” stuff to the “old” stuff? Does it make sense that I even start doing it?

Unfortunately, many times the answer to these questions leads to a categoric deception: we can do with the old technology, and that there is no need to introduce “new” stuff. While we should be trained to accept this outcome, we are not, and end up choosing the new cool and sexy stuff instead.

Picking stable, mature technology, despite its known shortcomings, should be the most traveled route for engineers, but unfortunately it is not. Specially in the context of startups, there is a desire to play with new technologies, somehow associating business innovation with technology risk.

Unfortunately, these risky technology choices later become heavy burdens that cost the venture either big bucks for paying star “talent” developers, big bucks for hardware and operations, or very low availability. In some cases, the technology might even become a dead-end and a re-engineering exercise is required anyway.

So, next time around, let’s try to think beyond our desk, and into the long-term implications whenever we chose a technology.