SE vs. Light

Our firm has succesfully built and marketed a Java Application Platform, affectionately known as JAP.

It essentially consists of an app server, a common tool set and a build/continuous-integration environment.

All JAP applications must run in the app server, so obviously it is only for Java EE applications. But what about the rest - is there a market for a JAP SE?

At this point I am not thinking about the benefits or the implementation of JAP SE, I am just contemplating the name.

One name that has been tossed up there is JAP Light.

From a good neuro-linguistic-programming perspective, I am wondering if that is the best choice.

On the one hand, light is way more palatable than heavy – heavy baggage, heavy body – yuk! On the other hand, I would rather be considered a “heavy-weight” performer than a “light-weight”, and the package we are marketing includes performance!

So is it JAP Light or JAP SE or other (I mean, if Java EE had come first, would they have named Java SE as Java Light?)

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.

Interviewing As A Service

I have been interviewing candidates for a Java spot and I have been using an interviewing technique that has proven extremely effective.

So often we hire a programmer and within the first week we find it was a mistake. Wouldn't it be great if we could learn in the interview what we would know after week-one?
I used to just give a written test that get's increasingly difficult and measure where they break.

But I have learned that many people can pass a hard test, even if they don't really know the stuff.

Here is what I have been doing -
First thing is the warm up - how are you, did you have any trouble finding the place?

Then just to take off the edge (and formulate first impressions) - what are you working on currently (or what was the last project you worked on?)

Next an easy question - what is a classloader - should answer something like "loads classes", although I am amazed how many candidates don't! Additional details such as delegation, initialization are all a plus, especially if the discussion is accurate.

Now comes the main part...
Write a thread that will concurrently write the system time to the system output log every 5 minutes.

I watch them do that. Did they sleep or wait? Did they struggle with the while loop? Did they use a variable or did they hard code "true" in the while loop? If a variable, did they declare it volatile? Did they synchronize?
If not, give them hints - this code will throw an IllegalMonitorStateException - what can you do to prevent it?

Watch them develop a few programs in this fashion. I might even walk out of the room "to use the bathroom" for a few minutes, to afford them some solitude.
(If they are not up to snuff I tell them so nicely, make a recommendation about something they should read to increase their bar, and send them on their way.)

Then another problem - implement the following method:
/**
 * Prints key=value for each entry in the supplied map
 */
public void printMap(Map map) {...}

Did they use the keySet or the entry set? Discuss the advantages of either/

If they get through that, give them a real architecture problem currently in the works, and collaborate with them on the solution.

Finally the closing - "What value can you bring to this initiative", "What would be your biggest concerns about joining our team", "Do you have any questions for me?" - Listen for any show stoppers.

A successful candidate will finish in 90 minutes.

I find this technique really separates the men from the boys, and can be used at any level and any programming language - Java, .Net, SQL, etc

It makes sense to have an "interviewing" department where interviews are dispatched as a service - "please give this candidate the core java interview" or "this candidate gets the .Net for MS Office applications interview."  This would ensure that every candidate hired adheres to a firm-wide measurable standard for whatever level he or she is  hiring.