The Revolutionary War was revolutionary in more than one way. Up until then, all military actions were directed centrally, by generals. The chain of command was primarily for transferring orders in a validated fashion. This kind of centralized control made sense when battles were primarily men hacking each other slowly to death. The advent of the gun sped up the battle, but it took the Revolutionary War to adapt to this new velocity. Washington introduced the idea of pushing responsibility down to the lowest level, which means the decisions are made at the point where they have the most impact.

Occasionally we see this principle in businesses -- Toyota, for example -- but most business leaders seem to hang onto the decision-making with the same grip as the old generals held onto their power. The mystique of the all-knowing decision-maker is strongly promoted by our monotheistic culture and the organizations that benefit from that; witness George W. Bush declaring himself "The Decider." And darn it all, it just feels powerful to be free of all those nagging fact-based doubts and just say the way it should be! People admire you, too. Being a decider is being a winner.

As guns make battles go faster, computers make businesses go faster. Used to be, businesses were like massive slow boats. You make a decision, and you could be dead before it has any impact. Your successors are left in shock, saying "he must have been ... guessing! We better not let anyone know about this." (Very neat: self-hiding mistakes).

Now, however, people might discover your incompetence within weeks, days, hours, or even instantly. This has been happening for decades, but continuing advances in computing are making it more and more obvious. Alas, it still feels really good to be in power. CEOs still make very disproportionate salaries, which helps imply that they know what they're doing (which is very important so that business schools can keep charging the big bucks).

But when executives make technical decisions that are outside their expertise, things can go wrong very quickly. This is especially true with startups; bad decisions cost investor money, impact schedules and can ultimately decide whether the company survives.

The most common place I see this is the most mundane: choice of client-side programming system. I recently visited (not a consulting job) a startup that was working on a technology that had nothing to do with computers. They happened to sell services over the web, but the fewer software engineers they have building their web interface, the more resources they have to focus on their primary skill, the thing that the company is all about.

Here's how I imagine this played out. A VP of this company is playing golf with other VPs, and the subject of web interfaces comes up. Another VP, full of fresh knowledge from some Microsoft-sponsored retreat, expounds for awhile: "Yes, Java is very popular on the back end" (Now that they have something to battle it with, they can acknowledge the obvious). "But the only reliable way to build a web app is with CSS, HTML and JavaScript" (More chance of getting the company to give up and only run on IE once they see how much work it is to be cross-browser). All the VPs nod sagely and file away these facts for their next decider moment.

Our VP goes back and hands down the decision. It might even go over very well if CSS, HTML and JavaScript are the only thing the programmers know -- but in that case the problem started before they were hired. And before you know it, the problems have exploded and the rate of feature addition has gone into decline.

At the company I visited, there was one programmer whose job was exclusively -- I kid you not -- to deal with IE6 bugs. No new features, just dealing with idiosyncrasies of one version of one browser. It may be job security, but what a waste of talent.

And what a waste of resources for the company to reinvent all these bug fixes rather than working on their actual product. Clearly all the AJAXy libraries may have reduced the problems but not solved them.

I'll go out on what I think is an obvious limb here, and say that CSS, HTML and JavaScript will never work without a lot of cross-platform pain. The design-by-committee nature of these beasts will always compromise them at the expense of the programmer. Take HTML5, the grand glorious solution that everyone points to as the answer to everything. Already compromised: from Wikipedia,

However, in July 2009, the editor of the burgeoning draft specification dropped the recommendation of the free software Theora and Vorbis codecs, after opposition from Apple and Nokia. This means HTML 5 does not currently specify a common video codec for Web development.

(This is probably also the answer to the question of why Google made its recent acquisition of On2 which makes codecs; if it isn't part of HTML5, then Google needs one to add to Chrome).

This is just one in a long line of cock-ups that have kept CSS/HTML/JavaScript apps from being cross platform. And it will never be fixed. Even if you believe that Microsoft, Mozilla, Apple, Google and others could even communicate well enough to agree on the meaning of the HTML5 spec and implement it identically, when will that happen? Anytime before HTML6 comes out? I've watched this long enough to see that you'll never be able to write a non-trival cross-platform web app using CSS/HTML/JavaScript. (Not to say that it won't be an improvement to have HTML5, but that you won't be able to assume it's available).

I think it's more likely that fancier applications will be targeted to Google Chrome. How different is it, really, to install Chrome as a browser than it is to install Java? Chrome is easier and less scary for the end user to install. With all the powerful things that Google is putting in Chrome, features that go far beyond ordinary browsers, developers will be attracted to the Chrome platform. Add to that the Chrome OS and the ability to use all that HTML5 goodness without worrying about the other platforms and it will become very appealing. And top it off with Google's ability to make things easy and comfortable for the end-user, and you have a real development choice.

There are other choices, of course. Microsoft pushes Silverlight, but really? It's going to solve the cross-platform problem? Which gaggle of Microsoft VPs is going to willingly give up the playing field and actively support those other browsers (sure, you can passively support them by saying it's OK to develop for non Microsoft browsers)? And what if something, somewhere, gets uncomfortable? Are you going to trust the company that spent hundreds of millions of dollars trying to reality-shift our brains so that we'd believe that Vista really is OK to not change their mind about this and decide that maybe Silverlight should only run on a Microsoft browser? Silverlight appears to be good technology, but I you just can't be sure if it will persist and spread.

JavaFX also appears to be good technology. It's cross-browser, no worries there. It does require that the user install Java, which has historically been a sticking point and a blind spot for Sun, and might get fixed eventually. That is, if the Oracle acquisition doesn't throw things into chaos for an extended period.

Then, of course, there's Flash/Flex. When I asked someone at the aforementioned company why they chose CSS/HTML/JavaScript, they said "we had to be sure that the user ...", trailing off because they realized that Flash is installed on basically every machine in the world. Anyone who uses YouTube has Flash installed. People aren't afraid of it.

Sure, it's not perfect. It's more open than it used to be, but not perfectly open, and some developers have a problem with that. I would argue that it's open enough for most purposes, and more importantly you can cut the UI programming staff of the aforementioned startup down to a couple of programmers, and those programmers could be pounding out fancy new features rather than coping with browser differences.

In the future, I would be tempted to try writing HTML5 on the Chrome platform. But in the present I still see Flash and Flex as the best options (Let's assume that those of you who can't resist the snarky comments at this point have already written them for previous blog posts). I'll end with a testimonial that was recently sent to me by Tim De Meyer, a senior Java EE developer at Cegeka, an end-to-end ICT solution provider located in Belgium. For the last 4 years he's worked on a large Agile project for the social security sector. He and a group of three others have been looking into Flex, and have this to report:

Just wanted to let you know that, after years and years of developing web based applications using JSF, struts, spring MVC and the like, we've started a small project (26 days) using Flex as the front-end. It's been quite an adventure so far, because we're used to taking an agile approach that comes with a few engineering practices we try to live up to.

So after some experimenting, we can now implement our user stories using our beloved test DRIVEN approach, writing jUnit tests for the java back-end, using FlexUnit to test our .as and .mxml files, and rounding it all up with some FlexUISelenium postdeploy-tests. And after a few days of struggling in Ant, we've now got a Hudson job building, testing and deploying our Flex app automatically. This results in a fully tested .war file we can hand over to our deployment team.

As for the technology stack, we're using the new Spring-Flex thingy to expose our spring POJO's as Flex destinations, and the Swiz framework helps us do a clean(er) job in Flex.

Although it's all pretty new to the most of us (we've got one experienced Flex programmer and 2 rookies who've just had some experience during an after-hours weekly workgroup), productivity has been great so far and our burn-down is telling us we're pretty much on track.

So I hope this turns out to be a success and that we can do some more projects where we can use Flex as the front-end. After the project is done, we're hoping to give an internal presentation in order to grow some interest in our Applications division. We've already gotten our program manager to start reading First Steps In Flex. As a former architect and developer, he's been very supportive towards these initiatives. Anyway, thanks for getting us, as Java developers, interested in the Flex world.