The Java Elephant in the Room

For starters, this is not a rant against Java. I like it…and I’ve learned not to enter a holy war about programming languages. There are many factors outside the exact language that go into what is used for what. So language choice is almost always about the entire ecosystem (integration ease, total cost of ownership, existing skills, etc..) rather than a strict esoteric choice of programming language. In fact, Java and C# are similar enough that I believe every .net programmer should learn Java at some point…but I digress.

This post is a caution to all who use Java or will use it in the future..and could also be titled: Diversity to Distraction. I’m calling out a * potential* issue with any Java development effort if not monitored and managed. Now, to their credit, many developers will self-mange the issue that I bring up, and that’s great. However, anyone involved in a development department should be aware and vigilant about the potential for distraction.

One of the biggest advantages of Java – it’s diversity and options at all levels – is also a potential weakness of moving a Java project forward quickly and efficiently. Let’s start with just the integrated development environment (IDE). There are many IDE’s available and having to debate or evaluate various IDE’s can take time and effort away from providing value to your customers. In my last company, the IDE was a straightforward choice – Eclipse. However, if not careful, we could have been easy spent a lot of time just with the different “flavors” of Eclipse! It doesn’t end there, either. For implementing various features, for example: a reporting tool/engine, it’s almost like a new product selection. Add to this, the need need to consider using JUint, Maven, Hudson and other life-cycle tools and it’s easy to go down a long, long rabbit hole.

The point is: Development teams need to be on the same page with their approach to what they are using. That means that the team needs to be brought together and – dare I say it – discuss and agree on the components and workflow of what they will use…or find away to constructively debate nuances so that time isn’t wasted with subtle power struggles between developers. In these kinds of situations, everyone needs to focus on the KISS principle. Simplicity at first and adding items incrementally. For example, start with a more generic implementation until there is a demonstrated need for something more specialized. If various components and life-cycle tools are introduced incrementally, there will be less disruption to the project and the entire team can learn workflows together as new items are introduced. No one has the luxury to spend endless hours evaluating everything out there…and you need to provide value to your customers earlier…and by the way, they don’t care which flavor of [insert item here] that you’re team is using – only that the software works.

Business Cliche of the Day (followed by the real meaning):  Let’s put that in the parking lot/let’s touch base on that later/let’s take this off-line  – “I’m never going to come back to your topic”


Veteran technology professional and manager

Posted in programming

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: