Center of the Universe Syndrome

It seems to be human nature to want to be "the center of the universe." It's no wonder astronomers thought for hundreds of years that the Earth is the center of the universe. From their perspective on seemingly solid, seemingly unmoving ground, everything else (planets, the sun, other stars) were the things doing the moving. We see other manifestations of this "center of the universe syndrome" in various facets of life such as daily life, business, and software testing. In this post, I look at how "center of the universe syndrome" can at least partially explain many of the bad decisions and dysfunctional behaviors software developers witness and/or commit.


There's No Team in 'I'
If we are to believe the resumes of software developers, everyone software developer is a team player. If I'm the center of the universe, then others should do what I want and do things the way I want. When they do this, they're team players. When they try to do it differently than my way, they are not good team players. As the center of the universe, I must be, by definition. a team player. After all, it's all about me.

I'll work only on what I want to work on. It doesn't matter if my skills and fellow team members' skills would be better used in a different configuration. It's only about me and what I want to do and what I think is worth doing.

The Customer's Always Right ... if (s)he agrees with Me
Customers are correct when they want things I know they need. When a client wants something that I know is unnecessary or not worth the effort required, it is the client's fault.

I am the Direction
If I'm the Center of the Universe, I'm also it's director. I don't need direction from leads, mentors, management, clients, etc. Everything should go the way I say it should go.

Resume-Driven Development
As the Center of the Universe, the most important part of my current project is development skills for the next job. It doesn't really matter if it's what's best for my client, my team, or my organization. I'll use whatever tools and techniques make my resume look better.

Ignoring Code Conventions
If I'm the Center of the Universe and I don't like or agree with a particular coding convention, the rest of the universe (other developers) need to come to my way of thinking.

There's Nothing Left for Me to Learn
As the Center of the Universe, if I think I know something, then that's how it is. Anyone who would tell you differently is simply wrong. Hopefully, they'll "get it" later. There's no reason for me to even consider that I'm incorrect or might need to change my mind. I'm the expert.

I Can Do No Wrong
If someone tells me I need to improve or finds fault with my work (including during code reviews or testing), then either that person is at fault or I have been mistaken for someone else, or I am taking the blame for someone else's misdeeds.

Everything's a Conspiracy: The Victim Mentality
As the Center of the Universe, it's unthinkable that I'd lose a job, not get a bid for consulting work, or otherwise not have everything my way. If I did get laid off or not win a consulting bid, it must be for some reason other than the fact that others considered were better fits or were cheaper or simply made a better impression. Only some type of conspiracy or discrimination could explain my not getting the bid or not being laid off.

Code Reviews are Necessary for the Others
As the Center of the Universe, I don't need code reviews, but I may be magnanimous enough to review others' code and set them straight. Actually, now that I think about it more, I probably won't even do that because I don't really care if they improve or learn new things. I'll just complain about how crappy their code is.

Instant Gratification
As the Center of the Universe, it's about me getting stuff slung out as quickly as possible so that I can move onto the next thing. I don't need to bother with things that slow me down and are mundane (testing various paths, testing at all, writing maintainable code, etc.). Give me credit for finishing the task quickly and let me move to the next fun things. Testing and maintenance can be left for others to do. The important thing is that I get to work on new, cool, and fun things.

My Task is Inherently the Most Valuable
It would make no sense to assign the most important tasks to anyone but the Center of the Universe. Therefore, my assignments and tasks are necessarily the most important. With this in mind, I should interrupt anyone and everyone to make sure my task gets accomplished as quickly as possible. Yes, I may distract others and delay their progress, but they're working on less important tasks anyway.



Conclusion

The software developer who acts as if he or she is the Center of the Universe is more likely to not see the big picture and to not understand the true significance of his or her role in the greater scheme of things. This developer is more likely to suspect conspiracy theories and invoke victim mentality when things don't go well than to try to learn and improve and do better the next time. The Center of the Universe is less likely to work well with others and to be open to new (and possibly better) ideas and concepts.

Unfortunately, it seems human nature to desperately want to believe and behave as if we are the Center of the Universe. We can't all be the Center of the Universe, so I propose that we simply agree that I'm the Center of the Universe and make it easier on everyone.

Three's Company: Oracle and Three Java IDEs

Many of us have wondered if Oracle would contribute to and support three Java IDEs. Before Oracle's acquisition of Sun, Oracle was already a contributer to the open source Eclipse (EclipseLink, for example) and already had its own free (but not open source) Java IDE in JDeveloper. With the acquisition of Sun, Oracle now has NetBeans in its fold. So far, Oracle seems to contribute and support all three. The following screen snapshot taken tonight demonstrates this (orange circles around the IDE names were obviously added to snapshot for emphasis).



As the screen snapshot above indicates, the Oracle Technology Network (OTN) main page features download-related links for all three of these Java IDEs. Just-released NetBeans 6.9 (15 June 2010) is featured in the right column of "New Downloads" and JDeveloper 11g is featured as a "free product" in the left "Top Downloads" column.

The Oracle Enterprise Pack for Eclipse (OEPE) is also featured on the main OTN page as a "Top Download." OEPE provides significant add-on functionality for Eclipse, including functionality covered in the articles Build a Java Application with Eclipse, Spring, and Oracle WebLogic Server, Web Services Support in Oracle Enterprise Pack for Eclipse, and Introduction to Oracle Enterprise Pack for Eclipse 11g JPA Workbench.

This year's JavaOne will be the first in which Oracle is in charge. Several presentations are NetBeans-oriented as documented in NetBeans at the JavaOne 2010 Conference, which lists eleven sessions that the "NetBeans team recommends."

Whereas JavaOne tends to be more general Java and less product specific, Oracle OpenWorld 2010 and Oracle Develop 2010 are being held in conjunction with JavaOne 2010 and offer numerous JDeveloper (especially Application Developer Framework) presentations. I'm not aware of any Eclipse-specific presentations at any of these conferences, but Oracle has shown significantly more interest in Eclipse in recent years than Sun did.

Oracle expressed interest in supporting the JDeveloper IDE, the NetBeans IDE, and the Eclipse IDE in their lengthy 27 January 2010 webcast. A concise summary of their stated plans for the three IDEs is available in the "NetBeans" section of the online post Oracle's Roadmap for Sun Technologies.

Although there are many other text/code editors out there and even other Java IDEs out there, Oracle seems to own or contribute heavily to three of the four "big ones" (IntelliJ IDEA being the lone major Java IDE without significant Oracle affiliation). The Java IDE I "grew up with" in the sense of first learning Java, (Borland at the time) JBuilder, is no longer the force it once was. JDeveloper has some JBuilder heritage, though it has obviously changed significantly since those days.

Based on Oracle's declarations regarding the roadmap for Sun products and based on the products advertised on the OTN page, it appears that the current plan is to continue providing support for JDeveloper, NetBeans, and Eclipse. I admit that I didn't think they'd continue supporting all three, but so far it seems that they intend to do just that.

Groovier Java RegEx Token Determination

In my last blog post, I looked at using a simple Java application to determine which characters would work as desired for splitting a String with String.split. Simple utilities like this one are often a perfect fit for Groovy and in the blog post I show a Groovy script version of the Java class featured in the previous post. I also demonstrate one Groovy gotcha.

Here is the Groovy script ported from the Java class detailed in the last blog post.

#!/usr/bin/env groovy

import java.util.regex.PatternSyntaxException

/**
 * This simple script accepts a String as a potential regular expression token
 * and demonstrates how this provided String work work as a token in a 
 * {@code String.split} invocation.
 */

NEW_LINE = System.getProperty("line.separator")

if (args.length < 1)
{
   println "${NEW_LINE}No argument was provided.  A candidate String token must be provided.${NEW_LINE}"
   System.exit(-1)
}

String candidateToken = args[0]
println "Provided token is: ${candidateToken}"

stringWithCandidateToken =
   "Java${candidateToken}has${candidateToken}regular${candidateToken}expression${candidateToken}support${candidateToken}."
println "String with candidate token is: ${stringWithCandidateToken}"

try
{
   splitStrings = stringWithCandidateToken.split(candidateToken)
   splitStrings.each()
   {
      println it
   }
}
catch (PatternSyntaxException badRegExpPatternSyntax)
{
   println "Unable to parse ${stringWithCandidateToken} on token ${candidateToken} using String.split method - ${badRegExpPatternSyntax.toString()}"
}

Although Groovy doesn't require exception handling even for checked exceptions, I intentionally caught the PatternSyntaxException (an unchecked/runtime exception) so that I could print out a little nicer error message than the normal stack trace.

The Groovy script writes out the same results as the simple Java application, so I won't show all the same screen snapshots shown in the previous blog post. However, there is one character that does behave differently with the Groovy script than it did with the Java application. When an asterisk (*) is provided as the candidate regular expression token for the Groovy script, the results are different than when it's provided to the Java application. In the Java application, the asterisk led to the PatternSyntaxException. In the Groovy script, something different happens:



Although the Groovy script version at first glance appears to have worked better than the simple Java application because it did not result in an exception, the whole point of this script and application was to determine an appropriate character to split on. This is a reminder that while Groovy largely IS Java, there are times when Groovy is different from Java.

In the case of the asterisk, Groovy tried to expand the asterisk first and it so happened that build.xml is the first file listed in the directory in which that script presides. As the screen output above indicates, the Groovy script thought that this file name was the token rather than *. This demonstrates that there are some issues with Groovy's handling of asterisk on the command-line as documented in Command line arguments containing * (asterisk) not passed correctly
and in Issues with the Windows startup batch files.

There are many things I like about Groovy and there are many ways in which it complements and enhances my Java development experience. This blog post has shown how Groovy can be very helpful in helping determine what works best with a Java API, but also demonstrates that there are some differences in Groovy and Java behavior that can mislead one if he or she thinks that Groovy always behaves exactly like Java.

Determining Valid Java Regular Expression Characters for String.split

The String.split methods can be very convenient for easily splitting a provided String based on a provided regular expression String. The only trick is figuring out a regular expression token to use to separate strings that are to be split that doesn't exist in the string naturally. For example, "e" would not work well because it is so commonly present in English text naturally. A related challenge in picking the appropriate regular expression token is to ensure that a symbol with special meaning in regular expressions (such as "^" for start of line) is not used.

I have blogged previously on how I like to develop simple Java examples to learn from. One example that has provided me benefit multiple times is a simple Java application that I can run against a String I'm considering as a regular expression token to be used with String.split. It is shown next.

Simple Java Application For Determining Viability of Regular Expression Splitting Token

package dustin.examples;

import java.util.regex.PatternSyntaxException;
import static java.lang.System.out;

/**
 * This simple class accepts a String as a potential regular expression token
 * and demonstrates how this provided String work work as a token in a 
 * {@code String.split} invocation.
 */
public class Main
{
   /** OS-independent new line. */
   public static String NEW_LINE = System.getProperty("line.separator");

   /**
    * Main executable function for running this test.
    *
    * @param arguments Command-line arguments: single argument is expected that
    *    represents the candidate regular expression token.
    */
   public static void main(final String[] arguments)
   {
      if (arguments.length < 1)
      {
         out.println(
              NEW_LINE
            + "No argument was provided.  A candidate String token must be provided."
            + NEW_LINE);
         System.exit(-1);
      }
 
      final String candidateToken = arguments[0];
      out.println("Provided token is: " + candidateToken);

      final String stringWithCandidateToken =
           "Java" + candidateToken + "has" + candidateToken + "regular"
         + candidateToken + "expression" + candidateToken + "support"
         + candidateToken + ".";
      out.println("String with candidate token is: " + stringWithCandidateToken);

      try
      {
         final String[] splitStrings = stringWithCandidateToken.split(candidateToken);
         for (final String splitString : splitStrings)
         {
            out.println(splitString);
         }
      }
      catch (PatternSyntaxException badRegExpPatternSyntax)
      {
         out.println(
              "Unable to parse " + stringWithCandidateToken + " on token "
            + candidateToken + " using String.split method - "
            + badRegExpPatternSyntax.toString());
      }
   }
}

This very simple example accepts a single string from the command line and attempts to use that string as a token for splitting a longer string into pieces. The example builds a generic string with the provided token and then splits on that token. The output of running this simple application tells how well that provided string works as a token.

The remainder of this blog post presents screen snapshots from running this simple application with some potential splitting tokens.

The first screen snapshot demonstrates running this application against a candidate token of "d". This actually works in this example because there's no "d" already in the string, but obviously would not work in most realistic situations.



In the second screen snapshot, the problem of using a common letter such as "e" as the splitting token is demonstrated. The strings do not split as desired because "e" existed in the string before tokens were applied.



The third example uses "^" as the regular expression splitting token. Because "^" has significance in regular expressions (start of line), it doesn't work too well as demonstrated in the next screen snapshot.



The "^" character is not the only token behaving this way. The next screen snapshot demonstrates similar behavior for "$" (end of line).



The "^" and "$" characters were not good choices for a regular expression-based token for splitting strings, but there are even worse choices. This is demonstrated for "*" in the next screen snapshot.



The last example, using "*" as the regular expression splitting token, led to an unchecked (but explicitly caught in my example anyway) exception PatternSyntaxException.

Parentheses also are significant in regular expressions (mark groupings). These don't work well as tokens for string splitting as demonstrated in the next screen snapshot.



As long as the colon (":") or semicolon (";") are not used naturally in the text being split, they work well in this scenario as demonstrated next.



The String.split method is not limited to splitting on a single character. In the next example, I use the three characters of the Groovy Spaceship Operator (<=>) as the token (and it works fine).



Finally, what happens when the "pipe" character ("|") is used for a regular expression token to split a string? Let's see.



The pipe is like an "or" in regular expression parlance and we see that behavior manifested in the example in the just-shown screen snapshot.

The Pattern class documentation (part of the java.util.regex package) documents "regular expression constructs," but the simple application demonstrated in this post provides an easy to way to determine and verify appropriate Strings to be used as tokens in splitting a string. A Groovy script version of this simple Java application is shown in my blog post Groovier Java RegEx Token Determination.

Looking Forward to JavaOne 2010

The 2010 edition of JavaOne features numerous presentations of interest to the Java developer in subjects such as JVM languages (Groovy, JRuby, Scala, Clojure), Java concurrency, HTML5 with Java, monitoring Java applications, cloud computing, modularity/OSGi, JDK7, REST/JAX-RS, Java Persistence API, NetBeans, JavaFX, and Java testing/debugging.

JavaOne 2010 is being held in conjunction with Oracle Develop 2010 and Oracle OpenWorld 2010. These major events are being held in simultaneously in San Francisco September 19-23, 2010. It looks like JavaOne 2010 and Oracle Develop 2010 (both developer-focused events) will be held in "The Zone," which is described as "San Francisco's Hotel Nikko, Hilton San Francisco, and Parc 55 hotels and the surrounding area." Oracle OpenWorld is hosted in the well-known (from previous JavaOne and Oracle OpenWorld conferences) Moscone Center.

A JavaOne 2010 Blog RSS is now available. This is useful for updates regarding JavaOne 2010. I'm particularly looking forward to the announcement of the availability of Schedule Builder to help with creation of a schedule of presentations to attend. The JavaOne 2010 Blog RSS feed has already provided an update on the Appreciation Event, which will feature The Black Eyed Peas, Don Henley, and Steve Miller.

I've already noted more presentations that I want to see than there will be time to see. However, with no dates/times yet available for the presentations, hands-on labs, and Birds of a Feather sessions, it is not possible to know yet which I am most likely to attend. The DZone/JavaLobby article JavaOne 2010 Accepted Talks lists some of the presentations, lab sessions, and BOFs accepted for JavaOne 2010, but they are all available (with dates/times "coming soon") on the JavaOne page.

In related news, the current Java.net poll asks, "Which JavaOne 2010 track will draw the greatest interest?" The tracks at JavaOne are all listed, but only one can be selected: Core Java Platform; Desktop Java; Enterprise Service Architectures and the Cloud; Java EE Web Profile and Platform Technologies; JavaFX and Rich User Experience; Java ME and Mobile; Java for Devices, Card, and TV; and The Java Frontier. My guess is that I'll attend many presentations from "Core Java," "Desktop Java," and "Java Frontier." Two of these three ("Core" and "Desktop") are currently leading the votes for most popular among other Java developers as well. Of course, several of the presentations are grouped into more than one track and often the Core, Desktop, and Frontier tracks overlap.

I previously publicly questioned if 2009 JavaOne was the last edition of this conference. Fortunately, it wasn't and I'm looking forward to the wide variety of topics being discussed at JavaOne 2010.

Software Debugging and Troubleshooting: Get the Facts First

I have written two previous blog posts on movie quotations applied in software development: Classic Movie Quotes Applied to Software Development (referenced in a CNN entertainment article) and More Movie Quotes Applied to Software Development. This blog post focuses on another single movie quote that sometimes is useful to remember during software maintenance and debugging. From my favorite movie of 2009 (Sherlock Holmes) comes this quote from Sherlock Holmes to Dr. John Watson:

Never theorize before you have data. Invariably, you end up twisting facts to suit theories, instead of theories to suit facts.

It is often useful to learn from our own experience and narrow down problems based on similar things we have seen in the past. However, there are times when we can jump to a conclusion too quickly because something looks very similar to what we've seen before. If we're not careful, we can waste significant time and effort chasing a certain possibility only to realize that we've wasted our time and, in the worst cases, perhaps made things worse trying to "fix" something that wasn't really the problem.

The quote referenced above from Sherlock Holmes is a reminder of the dangers of assuming too much before gathering sufficient data. Without sufficient data, it is easy to start seeing what we want to see. If we think something is the problem, we want symptoms to fit our preconceived notion of the proper solution or fix.

This effect is not limited to software development. A similar effect is often seen in a wide variety of things: politicization of science, the phrase "love is blind," and parents' sometimes inability to think their kids can do any wrong.

In most situations, including software development, the best decisions are made with better data. There are times when the cost of obtaining additional data is so high that we're better off starting to make decisions without the additional data, but in cases where it is relatively inexpensive to gain more data about a problem, that small price is usually well worth it. Making a proper decision early in design, in refactoring, and in fixing a problem can often result in a much quicker implementation or resolution.

As alluded to above, the dangers of jumping to conclusions without sufficient data are not limited merely to wasting time on a wild goose chase. In even more costly situations, grasping at straws or desperate fixes for theorized problems can make code unnecessarily verbose, worse performing, needlessly complex, or just plain wrong. Anytime code is changed, there is some potential for breakage. Changing code for no reason other than we think we're fixing a problem that's not really a problem introduces this risk with no benefit.

Making decisions based on previous experiences and applying past experience to current and future work are often beneficial practices that improve or productivity and efficiency. However, these tactics can be detrimental when we decide to design a new system or troubleshoot the existing system solely on previous experience even when the new problem is only remotely related or not related to our previous experience.

The best way to deal with this is to understand well the lessons learned from the past (how and where they apply) and to learn as much as we can about the given problem to know how it's the same and how it's different than our previous encounters with a seemingly similar issue.

JDBC on DZone in May/June 2010

Several useful features related to JDBC have been posted on DZone/JavaLobby recently. I briefly reference these here.

JDBC Best Practices: Latest DZone RefCardz

The latest DZone Refcardz to be released is the JDBC Best Practices Refcardz. The DZone overview of this Refcardz states the following:

JDBC Best Practices has something for every developer. This DZone Refcard starts off with JDBC basics including descriptions for each of the 5 Driver Types. This is followed up with some advanced JDBC on Codeless Configuration, Single Sign-on with Kerberos, Debugging and Logging. We even threw in a SQL Quick Reference to round things off.

The ABCs of JDBC

Daniel Rubio has posted a series of articles with the title "The ABCs of JDBC." So far, they are:

• The ABCs of JDBC, Part 1 - Getting Started with JDBC
• The ABCs of JDBC, Part 2 - ResultSets
• The ABCs of JDBC, Part 3 - The JDBC API
• The ABCs of JDBC, Part 4 - Stored Procedures

New Challenges in JDBC Usage Patterns
(Added 14 June 2010)

New Challenges in JDBC Usage Patterns is a video that, according to the DZone link, features "Jesse Davis [giving] us an update on what's happening at the JDBC expert group in the JCP."


Conclusion

I am happy to see that I am not the only one that still sees advantages to learning and using JDBC even in these days of NoSQL and ORM popularity. As I wrote in SQLPhobia: The Irrational Fear of SQL, JDBC can be the appropriate solution in some cases. I especially like how easy it is to use JDBC with the Spring Framework.

Blog Posts I Wish I Had Written

I started this blog in October 2007 and have written hundreds of posts with a few that I'm particularly proud of and/or that have been particularly well received. Besides my own blog posts, I read many blog posts each week (particularly if highlighted on JavaWorld, Java.net, or DZone). Over the many years I have been reading software development blogs, I have read many useful and informative blogs and written a few that I like to think fit in the same category. However, five blog posts stick out in my memory as so effective that I wish I had written them; I briefly reference and describe those five here and explain the reasons I wish I had written them.

All of these posts share at least one common trait: they are linked to and referenced from my blog multiple times.


I Couldn't Have Said It Better Myself

I was contemplating writing a blog post about too much simplicity not being a good thing (similar to my post about flexibility being turned from good to bad when applied in excess) when I ran across the post Simplicity is Complicated. As I read this post, I realized that there wasn't much more I could add to this, so I didn't try. Of all the posts on my list, this may be the one I most literally wish I had written.


Bucking the Trend with Substance and Being Correct

Today, EJB's 101 Damnations probably seems like nothing too new. At the time of its publication, however, it was one of those contrarian viewpoints I enjoy so much for challenging the establishment when a challenge is merited. The problem with some contrarian blog posts is that they lack substance behind the assertion that "such-and-such sucks." The "EJB's 101 Damnations" is full of detailed explanations that poke holes in the early problematic EJB specifications. EJB has come a long way, partly due to articles like this one (and also due to external forces such as the Spring Framework).


Changing the Industry

The blog post Ajax: A New Approach to Web Applications had exactly that effect: it ushered in a massive change in how many web applications were and are developed. Many developers have since claimed that they were using the same set of technologies or similar sets of technologies to do the same type of thing before this, but what Jesse James Garrett did with this post was to coin a catchy term and outline the basics and concepts of the approach in a manner that was readily accessibly to the masses. I wish I had written a post like this for purely selfish reasons: it would be something to have this type of effect on our industry. Garrett never claimed to have made up the approach of using existing technologies in such a way to make a more dynamic user experience. Indeed, he even cites two already existing examples (Google search engine's Suggest feature and Google Maps) right off from the start. He and his colleagues simply coined a term and wrote this introductory post that sped up the rate of adoption dramatically.


Generally Helpful

Tom Kyte's post Free Things I Use... is excellent because it pointed me to some products that have made my life much easier since then. He lists many tools he uses that are generally of interest to software developers and database administrators. I have seen similar posts by other authors since then, but this was the first one like this that I recall reading and being a beneficiary of. It's nice to have investment in reading of a particular blog post pay for itself many times over and my time reading this post several years ago has paid for itself over and over and over since then.


Specifically Helpful

These are the types of posts I like to attempt to write most often. These are also the types of posts that motivated me to write that more software developers should write blogs. I have been aided countless times by blog posts and forum threads explaining why I was seeing a strange and unseemly exception or error message or unexplainable behavior. The one post that comes to mind, though, when thinking of a specific, focused post that has made a major difference in my understanding is Common E4X Pitfalls. When I was first learning and using Flex and E4X, I visited this post frequently. This is the type of post that truly epitomizes how software developers can help one another. While most of the information in this post is available in other sources, it's value includes the organization of it all in one location in a concise but thorough presentation. I often don't need blog posts that tell me how to do something (because of the many great how-tos and books already out there) as much as I need something warning me about what not to do or warning me about tricky, less advertised corners. Common E4X Pitfalls does just that for E4X.


Conclusion

There are, of course, hundreds of really good blog posts and thousands of good blog posts out there. There is no way that any developer can read even all of the "good" blog posts. Do you have a favorite blog post that you wish you had written or that you repeatedly reference or have bookmarked, or have even printed out to post near you? I'd love to learn about blog posts that have had this type of effect on fellow developers.