Lean and Green vs. Gregarious Java Application Platform

There are 2 competing goals for our Java Application Platform (JAP), which I am trying to understand on balance:

One is the goal of on-boarding great numbers of applications onto JAP

The other is the goal of engendering best practices and standards across our firm.

I had a conversation with a group that is in the process of migrating to JAP and they told a tear-jerker of a 3-month ordeal before the Project Review Board.

Basically, had this group not inaugurated the JAP migration, they would not have been called before the inquisitioners to account for their use of shared databases, http (no “s”) calls, Hibernate (not a firm standard) not JPA, JavaScript, ehCache, and other technologies that we label as “non-standard” or “non-best-practices”.

Their complaint was – “we have been doing this successfully for 8 years, why should we need to build a new solution that adds no business value, just because we are migrating to JAP?”

At first, their argument made perfect sense to me and I was ready to take up their case. But then I started wondering if the thinking is more future-centric – that perhaps as a firm we should prefer a JAP that is leaner but greener – that only admits applications that comply with best practices; or should we prefer a more gregarious JAP that enjoys great traction, but admits applications that use old practices.

In other words, do we forfeit the numbers for the sake of fostering best practices and firm standards? Or are these orthogonal considerations and so do we allow people to do a direct port to JAP, then allow them to manage the evolution of their changes as their business sees value?

Facebook Driven Development

I recently had a conversation with a software engineer from a young but apparently pretty successful social networking/blogging startup.

They are currently hosting billions of blogs and enjoying millions of hits per day.

The conversation was extremely frustrating - I asked him about their QA - they have none - developers do their own QA - I asked him - "don't you find bugs in production" - unexpectedly he admitted - "oh yes, we always find bugs in production - we just fix them." (Thinks me - what about serious bugs; what if they aren't easily fixed; how can you push untested code to production?)

Then he told me their front end was all in PHP - I questioned the use of PHP for building serious front ends in the 21st century (ok, I am sure people will disagree with me on that, but fact is,  PHP is very popular among newbies and that scares me!) Anyway, his reply was Facebook uses PHP for all their front end work, so how bad could it be. I referred to Edsger Dijkstra's famous quote about Basic - "It is practically impossible to teach good programming style to students that have had prior exposure to BASIC; as potential programmers they are mentally mutilated beyond hope of regeneration." and I said that to an extent the same holds true with PHP. (Again, not being a PHP developer, I would stand corrected on this point!)

Then I asked him if they were agile! He told me they are, and they have 2 week iterations, but they release to production at least once per day, usually more. I pointed out that in most agile shops, they have a 2 week iteration, and then after every few iterations they have a release. But in this case, they have 2 week iterations and release every day, so what is the point of an iteration. He quizzically pointed out that he didn't understand my argument - if you have good changes, why hold them back? And besides - (you guessed it!) Facebook does it that way!

Now, my first question is - does Facebook really not have QA, really use PHP, and really use agile for daily releases?

And second - how can a serious client facing application use such (what are in my opinion) shoddy practices?

Look - I am in financial and this guy was a dot commer - 2 different universes. So I am sure he thought I was the bizarro (and he may be right)

But am I completely crazy? Obviously Facebook (and for that matter, this company) are way smarter than I!

To OSGi or not to OSGi?

I had a long discussion with Peter Kriens of the OSGi alliance after his JavaOne 2011 presentation “Why OSGi?’. In that talk he made a pretty compelling case that we are in the midst of a progression of visibility control that has been introduced first by subroutines and functions, then objects with the advent of SmallTalk, then packages, and now modules/bundles, (And next, perhaps something around WebServices?) that has been evolving in a world of growing and more complex code bases.


I expressed to him my main concern about moving to OSGi as a firm standard - the cost of financing the learning curve. Peter’s suggestion was to have a little tooling and a small trained OSGi staff that can set up the skeleton of each project and hand that off to the development teams, who can then remain blissfully ignorant of OSGi.

The reward – more maintainable code in a milieu where the amount of software written will double in the next 6 years.

I asked him about project Jigsaw and his feeling was that it is missing the boat – only scoring a 2 or 3 out of 5 on his Modularity Maturity Model. He also said Mark Reinhold and team have a lot of learning curve ahead of them and his opinion was they will never catch up with OSGi!

Ok, I would expect him to say that, but I am inclined to believe it, especially over the next 3 or 4 years before Jigsaw enters the scene.

My big question is – are firms ready to stand behind OSGi as a basis of a platform?

My feeling is that something like Paremus has a light footprint, fast startup, auto scaling, multi-tenancy, and provides standard SE functionality plus basic JEE functionality (courtesy of CXF and open EJB) all without an app server. If not Paremus, there will probably be entries by larger companies coming, perhaps GlassFish is already that, but I prefer Paremus because it accommodates non-OSGi code side by side, providing for an evolutionary migration strategy.

But will CIO's agree with that argument (which is largely based on the nebulous benefits of modularity) or will it all come down in the end to the basics – what is the cost saving, enterprise apps require Java Enterprise Edition, why support multiple containers, etc. etc. Egad! If we made those arguments in the 80’s we would still be programming in PL/1!



Can we make a business case for JAP SE that is largely dependent on OSGi?

I am anxious to hear your opinion.