Java SE - could it be more pointless?

Back in 2007 I gave a presentation on Java whose theme was that Java had won.

On slide 12 I put forward a proposal that I'd talked about here before as well in that Java needs to be professional and critically reduce to having a small core on which people can innovate and develop whether that be in smartphones, desktops, servers, virtual machines, smart cards or anything else that people dream up.  Simply put Java SE has no point in today's IT landscape as the 'primary' release on top of which everything else is done.

When I look at how SAP are pumping new life back into ABAP and how other languages are exploding, not because they make things better but because they address specific niche concerns.  High-performance computing still reverts to the assembly languages, in part because Java's bloat means it can't be tuned down to the core that they need.

The question is whether anyone has the guts to make the change or just continue on the road to obscurity.

Java needs a revolution, not another poor attempt at intelligent design.

How to weed out bluffers....

Following up from the concept of thinking being dead I'd like to talk now about one of the biggest challenges in IT.

How do you spot those people who are bluffing?

And here I mean people who don't really think they are bluffing because they are rubbish, or those that are bluffing because they think you are rubbish, its related to the challenge of Terry Pratchett Architects (PArchitects?) where how do you tell someone who distaines technology through knowledge v one who distaines through ignorance? The point is this:

95% of people interviewing senior IT people don't understand enough to weed out bluffers

This means that regularly I come across people who have a senior position based on a level of buzzword knowledge and general ignorance of reality that causes me to step back in amazement at the ability of the person to hold down a job. Normally of course these people are in jobs 12-24 months and often are contractors where such variability is almost seen as a benefit rather than an indication of being found out. So here are the top tips on weeding out the bluffers, and I'm assuming here we are at the Architect level and you can weed out bad developers...:

1. Don't do it in a phase 1 Tech, phase 2 HR interview process - add in a middle phase which is set up by phase 1. 
2. In Phase 1 ask the following 
1. When was the last time you coded into production, what language, what plaform? 
2. When was the last time you created a conceptual and logical data model? What platform for? 
3. What is the difference between Regex, Regular Expressions and Perl in string handling? 

The first two are the real set-up questions... the last one is something that stunned me once when someone I was interviewing kept saying "I did Regex" and then later on said 'On that project we used Regular Expressions', I asked him the difference and he said that Regex was a language, Regular Expressions was... a different language. The point here is that you are after an understanding of the languages and platforms for which this person claims some level of expertise.

Lets be clear here, I'm of the opinion that an architect, whether Solution, Enterprise or Business who claims to sit within the IT domain should still know how the platforms work and especially should remember how their last platform worked. In the second interview you should include real deep developers, get them to ask real deep developer questions. You aren't looking for 'this person is a bitch ass programmer in language X' but 'not brilliant, but seems to know his stuff generally'. What you are looking to avoid is 'I don't think this guy has ever used X in his life' or similar statements.

Similar approaches, but more abstract should be used for PMs and BAs where you should get PMs and BAs who have done similar technical projects to ask the questions. I'm stunned at how many times I meet someone who is a 'Functional' SAP BA and then when you introduce them to someone who really is a functional expert in that area they fall to pieces... sometimes not even knowing the acronyms of the SAP modules they claimed to have used ('We did supplier management, not sure what SAP called it') The point here is that you need a first stage to find out where the bluffer claims to have depth and then a second stage to rip the hole if it exists.

Bluffers florish in a world where thinking doesn't exist.