jonr originally posted this on Jon Rose's Blog.

My boys over at InfoQ just posted the big news!!!  With JavaOne around the corner, SpringSource released a non-JEE application server. Spring founder, Rob Johnson, explained the main motivations for the release:

“Rod pointed to a number of pain points with today’s current development/production environments such as the duplication of meta data across configuration files, the fact it is common for projects to in essence deploy a server on top of a server (deploying your application along with many tools and frameworks in the same deployable unit), meanwhile they were mostly using only the web container portion of their appserver. SpringSource as a result wanted to provide a simpler platform based on today’s development needs.”

The Spring Framework was game changing when it came out and started to take over a large portion of the J2EE market,  to the point where many projects really only use Tomcat now - along with the different POJO frameworks.  So, this may be a revolution that has already happened, but it is still very interesting.   I cannot wait to see how the Java world reacts.

jonr originally posted this on Jon Rose's Blog.

I have been working on a project with a very complex domain for the last year and a half.  Our team has been doing our best to make use of agile principles, but I am seeing a few places where Agile breaks down.  The greatest challenge for our project is that the stakeholders do not have a complete or clear understanding of the domain.  This isn’t necessarily their fault, as we are replacing an old main frame government system based on 30 years of convoluted and conflicting legislation.  Within those realities agile makes a few implied assumptions that limits its usefulness on our project:

1) That a clear understanding of the domain exists somewhere, and you must work closely with those individuals to extract that information.

2) That there is something for the stakeholders / users to interact with as the project iterates (i.e. a user interface).

In addition to the ongoing new domain revelations that we seem to continually be discovering along with our stakeholders, the guts of the application we are building computes complex tax calculations that run in a batch process like fashion, using attributes across seemingly countless domain objects.  This means that often the only artifacts to deliver to the stakeholders at the end of an iteration are reports - reports that have to be near complete in order for the stakeholders to make sense of them and be able to compare with the previous systems results (main frame / Excel).  This makes it extremely difficult to quickly iterate and get the necessary feedback to finalize the systems most difficult features.

The reality is that there isn’t a methodology that can fully address issue number one, but it is important to realize that there are issues that methodology cannot solve.  Another example of this, is expecting Agile to compensate or gloss over poor performers.  This is a common one and of course never works, and it only serves to set the methodology up for the blame when things fail. 

For our project, it is important that we iterate in hopes of getting feedback as early as possible, but that doesn’t necessarily mean that our stakeholders ongoing ‘new discoveries’ will come any earlier in the process.  I do like Agile and think it can solve a number of problems, but I often feel that it is over emphasized.  It is just one part of a software project.  To really succeed in building quality software highly competent people are required – methodology should only be enhancing their efforts.  I hope that is a fairly common thought.  I guess the new realization for me personally is that you also need highly informed (in both the domain and methodology) and motivated stakeholders too…

jonr originally posted this on Jon Rose's Blog.

Adobe’s James Ward and I just finished up another Flex Top 10 for InfoQ.com, this one outlines the common mistakes when building Flex applications. I am happy with how this one came out, as it is packed with loads of good content. Check it out to learn how to make your Flex applications even better.

jonr originally posted this on Jon Rose's Blog.

I just finished up a post on Flex and the Open Web for InfoQ, summarizing Adobe’s Ryan Stewart’s response to critiques saying that Flex breaks the open web. I understand that Adobe has to do their best to win over the entire software community, but I for one care little about standards. They do have a role in the industry, and I wouldn’t throw them out all together. However, I think any claim that they will lead us to the future is simply wrong. Standards can only capture the lowest common denominator, and rarely if ever lead to innovation. They are the rear view mirror of what has already happened in the industry.

We need to look no further than the JCP for an example of how standards have failed the industry. The JCP sounded amazing on paper, but the reality was countless specifications that didn’t work. Is anyone still using EJB? Of course, but they are using EJB 3.0 – the rewritten specification that captured the innovation that happened outside of the standards process. I cannot think of a truly successful JSR where that isn’t how it came to be…

So, do standards matter when it comes to Flex? I would say yes and no. First off, the Flash Player is a defacto standard and the closest thing the Internet has to a truly ubiquitous runtime on the desktop/browser (Windows, Mac, and Linux). This brings us back to the lowest common denominator. If you are building an application that has to be available on all desktop and mobile platforms, they really should be using standards based technologies to ensure all of your users can access the application on the latest and greatest. On the other hand, if you are building an application for consumption through a traditional browser (or desktop with AIR), then you really should be considering Flex or some other rich client runtime (Silverlight, Java, etc…) – otherwise your users are missing out.

As with all things, it is important to choose the right technologies for what you are building, but don’t be afraid of platforms that go beyond the standards. In contrast to what seems to be the common wisdom, it is unlikely that the platform vendors are trying to screw you by including advanced features that are outside of or beyond the standards – they are probably just trying to give you the features that you need to succeed for your stakeholders.