O JavaFX, What Art Thou?

I have read about and started to learn about JavaFX twice and both times have been "strikes" in the sense that there wasn't enough there to really use. Both of these forays into JavaFX occurred at the time of 2007 JavaOne and 2008 JavaOne as a result of the pomp and ceremony at these conferences regarding JavaFX. Both times, I stopped wasting my time because I realized that it wasn't ready for prime time yet. As in baseball, the third strike is a strike-out, so I've been hesitant to investigate JavaFX or spend any more time on it unless I'm convinced it's finally something more than bluster and slideware.

The announced Oracle acquisition of Sun led me to wait for that third try until after Oracle had made its JavaFX-related intentions clear. Oracle has now done that and it sounds positive for JavaFX. Use of JavaFX for this year's Winter Olympics in Vancouver has also been among JavaFX's biggest and most positive recent news.

In most of my posts, I either write about things that I have learned from experience (cogitations/observations) or that I am guessing about (speculations) based on similar experiences in the past. In this post, I am going to postulate a bunch of questions about JavaFX in hopes that someone can authoritatively articulate answers to these questions. These are high level questions that I want to know the answers to before investing any more time or energy into learning JavaFX.

One of the difficulties I have encountered with JavaFX is distinguishing between JavaFX features that are and JavaFX features that are to come. Many of the JavaFX documents seem to be optimistically written about what it will do, but often in terms that are ambiguous as to how much of that is done today and how much of that is still the vision. I hope I can get clearer answers in response to this post.


What is JavaFX's License?

The JavaFX license has always seemed a little complicated, but this is not completely new as some other products have similar complicated licenses. According to the Wikipedia article on JavaFX, the Java FX license is really a collection of "various licenses for the modules that compose the JavaFX runtime" that include the proprietary runtime, GNU GPL, and the "normal" Java-esque dual license of GNU GPL/CDDL.

I'm not the first to wonder about JavaFX's license(s). Related posts on the subject include JavaFX: Sun isn't sure about the license (23 May 2007), The JavaFX Trap (1 August 2008), and The JavaFX 1.0 License - Completely Unreasonable?.


Is JavaFX Open Source?

Partly. As described in the section above on licensing, there is a portion of JavaFX that is open source, but significant portions are not. The openjfx site now forwards one to the JavaFX.com site.

Again, I'm not the first to wonder about the degree of "open sourcedness" of JavaFX. Others have posted questions on this topic in posts such as JavaFX: Open source or not? and the JavaFX forum thread Is JavaFX open-source? I particularly like the latter (the forum thread) because it nicely covers the intricacies of making a product like JavaFX open source.


Is JavaFX Standard?

As far as I can tell, JavaFX is mostly proprietary, was owned by Sun, and is now owned by Oracle. I'm not aware of a standard that multiple implementations can be written to. Despite its problems, the Java Community Process (JCP) has been the process by which "standard" portions of Java (both SE and EE) have evolved. I'm not aware of any Java Specification Request (JSR) for JavaFX? Is there one? I'm similarly not aware of any standard upon which JavaFX is based nor any implementation to compete with it directly (same syntax, etc.). In other words, is there another implementation I can switch to without changing code if I don't like something about the current implementation (similar to switching Java EE application servers or JVMs)?


Is JavaFX Java?

JavaFX certainly has the four letters "J-a-v-a" in it, but so does JavaScript (which is not Java at all). The JavaFX FAQ touts one of JavaFX's advantages being the ability to leverage Java developers' experience and one question/answer in the FAQ talks about running JavaFX applications on any device with a Java Runtime Environment.

I have a difficult time thinking of JavaFX as "Java" for several reasons. First, the syntax of F3-inspired JavaFXScript is not that similar to Java and it is my opinion that a Java developer will have as easy or possibly even an easier time learning JavaScript or ActionScript than learning JavaFXScript. Second, to me, Java is about standards. JavaFX, as far as I can tell, is in no way standard. It might be Java-based (as are Google Web Toolkit, Pivot, and so many other frameworks), but it's not Java. Third, JavaFX integration with Java is not quite as easy as I'd like for something that is "Java" itself. For more details on integrating JavaFX with Java, see Closing the Gap Between Java and JavaFX and Calling JavaFX Classes from Pure Java Code.

On the other hand, JavaFX does seem to enjoy some traits of "Java." One, it shares the four previously mentioned letters. Two, it has the "write once run anywhere" mantra of Java. Three, it makes heavy use of "Java infrastructure" such as the next-generation applet and Java ME. Four, it can use the wealth of Java SDK libraries and third-party libraries and so enjoy advantages enjoyed by languages such as Groovy and Scala.

For me, whether my client-side technology is "Java" is not all that important. What's most important is how well my client side technology interacts with my Java server-side software. This is why I've liked Flex+Java so well. I have benefited several times from the ability to easily swap clients against the same server-side software. JavaFX doesn't feel very "Java-ish" to me, but I also don't consider that to be a significant disadvantage. If JavaFX provides capability to talk to my server-side software via HTTP, SOAP, REST, and JMS like Flex does, then that's good enough.


How Large is the JavaFX Community?

This is a difficult question to answer and it is even more difficult to how large it can become. On the encouraging side, there have been numerous postings online about JavaFX. The trick, of course, is deciding if this is a sample of a large, growing, and vibrant community or is more a matter of a relatively small number of enthusiastic developers.

Java.net polls have provided some indication of how large the JavaFX community is and how large the potential community might become. There was a poll clear back in 2007 as well as a relatively recent poll. I get the feeling that many Java developers still have a "wait-and-see" attitude toward JavaFX. Considering the huge fanfare over JavaFX in 2007 JavaOne and 2008 JavaOne and the long wait after those events to get something tangible, this attitude is to be expected.

Of particular concern is David Herron's comment in his blog post The iPad, the Flash kerfluffle, Applets and JavaFX regarding attendance at the Silicon Valley Web Java Users Group:

How many of you are interested in JavaFX? A meeting of 100+ geeks in Silicon Valley who are associated with a Java User Group, you'd think a few of them would be interested in JavaFX. One person raised their hand. I think that says a LOT.

Does JavaFX Have a Niche?

Related to community size is the question of what JavaFX has to offer that might set it apart from the rest of the crowded field. It is difficult to find a front on which JavaFX doesn't have a mighty competitor to face, often more entrenched than JavaFX. For web-based RIAs, JavaFX is playing catch up with Flex and Silverlight. Many developers choose to not use Flex or Silverlight because they prefer something more standard, but that's not JavaFX (as far as I know -- see question above). Even if JavaFX was standard-based, it would have to compete with several Java-based standards (JSPs/servlets and JavaServer Faces) and with one of the biggest standards of all: HTML. HTML 5 finally seems to be gaining some traction and could be a formidable foe.

Mobile devices seems like a decent niche for JavaFX with wide availability of Java ME. However, the rapidly growing popularity of iPhone and Android-based telephones are making Objective C and Android compelling platforms for mobile devices. The irony here is that Android is arguably "more Java" than JavaFX.

With JavaFX competing for market share on the web against Flex, Silverlight, HTML 5, Google Web Toolkit, and many others and with JavaFX competing for mobile market share with iPhone and Android, the desktop seems like one of JavaFX's best frontiers for success. If JavaFX and Swing were made more easily integrated, this could be a very compelling combination.

One of JavaFX's selling points is the ability to run on all the aforementioned platforms: web, desktop, and mobile. On the surface, this is a really nice feature that could save development time and provide users with consistent experiences. However, given the significant differences in these platforms and in user expectations for applications on these platforms, I'm less sure of the value of this proposition.


Where Does JavaFX Fit with Oracle?

My belief is that the Oracle acquisition of Sun may be the best thing that could have happened to JavaFX in terms of its future viability. Oracle may be able to turn JavaFX into a profitable product and therefore justify continuing heavy investment in it that Sun started.

I think Oracle has provided a model for the likely treatment of JavaFX in the future. Keep in mind, that this is pure speculation (one of the key components of my blog's title). I think that Oracle could treat JavaFX like they have treated the Oracle Application Developer Framework (ADF). As I understand it, a developer can download ADF with JDeveloper for no charge and then purchases runtime licenses on a per processor basis (see Oracle's ADF site for complete and correct details). I've never used ADF, but I understand that it's a convenient framework for simplifying Java EE development. It is most likely not more familiar to more developers (such as me) because of its proprietary nature. It's standards-based, but is not itself a standard.

I personally am not stuck on something being open source. If the best product for my needs is not open source, then it's still the best choice. If all else is equal, I'll typically choose the open source product, but I'm not afraid to carefully use a proprietary solution (especially when it's free or low-cost) when its advantages are obvious and its use is handled correctly (sufficiently isolated and abstracted). I think JavaFX could have a reasonably successful future under the ADF model, but it's unlikely to be as successful (in terms of usage) as it would be if it was free and open source.

No matter what happens with JavaFX under Oracle's stewardship, I think it is important to remember that the much-revered Sun already had JavaFX as a proprietary, non-standard product with some open source pieces before Oracle ever had any rights to the product.


Does JavaFX Have a Future?

Since the Oracle acquisition, I have felt that JavaFX likely will be around 1, 2, and even 5 years from now. That being said, I am still not convinced that it will ever be "the" or even "a" dominant display technology, at least as it stands today. Instead, I see it as a promising alternative that might be the best fit in certain situations (such as when the ability to run on multiple platforms' screens is of vital importance) and not the best fit in many situations where a competing and likely more established technology already provides a better fit.

As I have thought about and written this post, it has felt to me like JavaFX is trying to find itself. I think it's getting closer to finding itself and, when it does, I may have to give it the third try and hope to avoid a strike-out.


Other Questions About JavaFX

Here are some other online postings of questions (and sometimes answers) related to JavaFX.

⇒ JavaFX Frequently Asked Questions

⇒ Ten Questions for JavaFX

⇒ Will JavaFX Ultimately Become a Widely Used Rich Client Technology?

⇒ What I Don't Like on JavaFX

⇒ JavaFX Basic Questions


Conclusion

In this post, I have recorded some of my questions regarding JavaFX along with my best attempt at answering those same questions. However, I'd appreciate any additional and/or corrective details that can be provided for me to better understand what JavaFX is and whether it is something I want to invest more time learning when I have competing interests in other "new things" (such as Android SDK development for my Droid).

Grab Bag: Android, JavaFX, and the Allure of Software Engineering

There have been a few recent online articles and posts that I think deserve mention here. These are related to Android being good for Java, praise for the field of software engineering, and a sense of what Java developers think of JavaFX.


Software Engineering: High Pay, Low Stress?

A recent Yahoo! Finance posting of a Investopedia article (Five High-Paying, Low-Stress Jobs) list software engineering as one of their five jobs with high pay and relatively low stress. Some of us may not agree with the stress part, but it is not going out on a limb to say most of us do have less stress than a combat soldier (referenced in the article as an example of low pay and high stress). Under "Computer Software Engineer," the article states, "many software engineers can work from home, since their jobs can be done from practically anywhere. Software engineers also bring home steep salaries, normally ranging between $54,000-130,000 a year. There's nothing nerdy about that."

Another position closely related to software development also made this list of five professions proposed to be high pay and low stress: the technical writer. The other three careers on this list are civil engineer, physical therapist, and massage therapist.


Android: Bringing non-Java Developers to the Java Fold

One of the effects of the rapid rising popularity of Android-based telephones is the new entrants into Java's ecosystem of developers from non-Java environments. For example, the author of the blog post Android Development - Debugging Your App starts that post with the sentence clauses, "Coming from a Windows environment, specifically the .NET space," and then goes on to talk about debugging in Eclipse.

The significance of this, of course, is that a whole new group of developers with little or no Java experience are now essentially working with Java itself as they develop Android applications and are using tools of the Java ecosystem such as Eclipse. Java may have originally been targeted at the web browser (applets) and may have in recent years become known as a technology for the enterprise space, but now it appears that it could be the Android-based handsets that bring standard Java (but not Java ME nor JavaFX) a growing base of users. Who would have predicted this before Android?


Java Developers on the Future of JavaFX

A recent Java.net poll asked the question, "Will JavaFX ultimately become a widely used rich client technology?" None of us have a crystal ball and these polls are obviously non-scientific, but I thought the responses were pretty inline with my own opinions based on talking to other Java developers about JavaFX. The respondents seemed to really consider the issue and provide a fair personal assessment. There were also several good comments added.

To the question of whether JavaFX will become widely used as a rich client technology, well over half of the nearly 370 responses were either flat-out "No" (18%) or the little less sure "Probably Not" (a whopping 40%!). About 16% of the responses were the tepid "Maybe" while about the same percentage were more positive and answered either "It's already widely used" (2%) or the much more realistic "The Version 1.3 Improvements Make it Likely" (14%). I don't see how anyone can think that JavaFX is widely used currently (unless the interpretation of "widely used" differs significantly from mine) and the results show that few legitimately believe that to be the case.

There are several observations from this poll. First, JavaFX still has more people thinking it won't become a widely used rich client technology than those who think it will. Second, I think this poll shows once again that the Java development community (or at least the members of the community who read Java.net and participate in the polls) are cognizant of what's happening around them. Third, the comments on this poll are really worth reading. I think they sum up pretty well some of the major concerns the majority of Java developers who think about rich client technologies have about JavaFX.

Reasons for Incompetent Software Developers Anywhere: Human Nature

The May 12 whyjava blog post Reasons for Incompetent Software Developers in India caught my attention. This post, which rightfully earned a Top Links position on DZone, is explicitly aimed at highlighting reasons why some Indian developers are less competent, but what I couldn't help think as I read his reasons is how they have applied to some of the less competent developers I have witnessed working in the United States. In this post, I look at the five reasons outlined in that post from a "western" perspective; some things aren't all that different because we're all humans.


The Importance of Wanting to Develop Code

I have long felt that it is important to really want to develop code to be successful in our industry. The reason for this is that most developers I know do really love what they do and most of us are better and do better at things we enjoy doing. Developers who tolerate but don't really have a passion for development are often at a significant disadvantage. There are many reasons for this, some of which are the nature of a passionate developer: more enthusiastic, more creative, more energetic, more involved, more willing to learn and improve at the craft, and on and on and on.

The author of the post Reasons for Incompetent Software Developers in India points out that many developers in India are "developer[s] by chance not by choice." I think there is some truth to this in the United States, but it is less of an issue now than it was in the mid- to late-1990s. In that time frame, the economic side of the software development community was very similar to what India seems to be experiencing: many projects and clients would take their chances on anyone willing to sling code because demand for software skills and labor exceeded supply. As demand has relaxed, the supply has as well. We've lost some good software developers to this, but a large percentage of those who don't really care much about software development have been affected by this.

It is human nature to follow the money. Many people don't care what the job is as long as it pays well. This may be fine for certain occupations, but it is a big disadvantage in software development.


Problems with the Education of Software Developers

When I read the post's author's primary complaint of higher education in software development in India as "importance is given to marks than to practical learning, students just cram the things and get score but practically they know nothing," the first thing I thought of is that he could have replaced "India" in that sentence with the name of any nation and it still would have been accurate. This seems to be another symptom of human nature: we do what is rewarded. Grades ("marks") are what help us get that first job, so priority one for most of us in college is to get the best grades we can get to land that first job. Of course, actually learning something is of benefit in keeping the job, but we're often (and not surprisingly) more worried about getting the job than keeping it. After all, you don't have to worry about keeping a job you never got in the first place.

Bjarne Stroustrup's article What Should We Teach New Software Developers? Why? (Communications of the ACM) provides a particularly credentialed opinion (in-depth industry experience combined with academic experience) on how computer science education needs to be improved even in the United States. I wrote more about this article in my post Must-Read Software Development Resources for 2009.


The Importance of Continuing Education

One of the stated reasons for the existence of some incompetent developers in India is "developers don’t keep themselves updated." This too applies everywhere and is closely related to the passion I discussed earlier. Most of us want the professionals who impact our lives (doctors, attorneys, real estate agents, dentists, civil engineers, architects, etc.) to stay current in their field and offer cutting-edge service. Users of software are no different than us and want the same from us. It's easier to invest the time and effort to learn more if we have a passion for what we do and if we truly want to master our craft.

Many developers do read blogs and articles and books, do attend conferences, do experiment or learn a new framework or language or library, and so forth, but many do not. Why don't more developers continually learn? There are many blog posts on this subject, but the explanation often boils down to we, as humans, having other interests and sometimes those interests completely dominate the desire or even ability to learn new things outside of the regular work week. The best situation, of course, is to learn new things on the job, but this can also lead to dysfunctional behaviors such as resume-driven development and Not Invented Here syndrome where the real motivation is to learn something new even when not necessary or desirable for the client.


Management is Where It's At?

The first three reasons listed for the existence of some incompetent developers in India were reasons that could be used to explain incompetent developers anywhere, including the United States. The fourth one did surprise me at first. The blog author wrote, "Everybody wants to become a manager." This is certainly not my experience with the majority of software developers in the United States. Many developers do end up in management through coercion (it's the only way to receive compensation past a certain level or to be allowed to make certain types of decisions), but most of the ones I know would stay in development jobs (especially low-level technical lead and architect positions) if the money, prestige, and career advancement were the same.

There are exceptions to any generalization, but I have noticed that, in general, the developers most in a hurry to move to management are those who lack any passion for development. This is sensible: why limit oneself's career growth or compensation for a job that holds no particular appeal over the job that tends to pay more or allows for faster career growth? The best developers generally seem to love development so much that they are willing to not "advance" up the ladder as quickly as they might because they are in no hurry to leave development. I earned an MBA several years ago thinking that I would one day need it. Instead, I've tried to carefully craft my career to allow me to focus on development and design as much as possible with minimal managerial duties as distractions. I truly enjoy being a technical lead and a mentor, but the Microsoft Project stuff and bean counting are not very appealing to me. It is likely that I'll end up in management roles again in the future, but I'm in no particular hurry.

There are exceptions to this, but they still take me by surprise. In a recent blog post, Bruce Eckel (of Thinking in C++ and Thinking in Java fame) stated "My interests have been shifting ... away from software development and towards business." This was surprising at first, but not so surprising when I considered a blog he wrote not too long ago called "Software Development Has Stalled."

It seems to me that software development is a little unique in this regard. In most industries, it is commonplace to want to rise as rapidly in the ranks as possible. Software developers want to rise technically and received recognition and accolades and better compensation, but the desire to "climb the ladder" doesn't seem as embedded in our brains as it is in the minds of others in other industries. I have even had managers (not developers) ask me why I want to stay in a full-time development position rather than move onto management. These individuals cannot understand this. So, again, what was described in that post about Indian software development may not be quite as true in the United States for software development, but it is certainly very true for the typical United States professional position.

I think we all benefit when software development managers have been successful software developers. It's my experience, however, at least in the United States, that many of the best developers I have worked with cannot picture themselves doing anything else but architecting, designing, and building software applications. In fact, as a beneficiary of many good software development managers (I hope to blog on the importance of good development managers in the future), I think it's very important to have qualified people in those roles and they are often important roles; it's just that the best developers often have no interest in those roles.


Giving Back: Open Source/Community Contributions

The fifth and final point of the post explaining the reason for some incompetent software developers in India is "No contribution to opensource community" and the post's author states, "I don’t know any of my friends or friends of friends including me who has contributed to opensource community." If one means actually contributing code to viable open source projects, I don't think the majority of developers in the United States do that either. However, if one means contributing to open source via writing blogs posts and articles, writing bug/enhancement requests, giving presentations, etc., then I think there is a much higher rate of open source contributions in the United States than direct code contributions. Even with the more widely arching definition of "contributing to open source," I think it's very safe to say more developers never or rarely contribute to open source than do contribute to open source.

Human nature yet again explains this phenomenon. Open source is, in some respects, a problem of the commons: we all stand to benefit from it, but it can be tempting to let others do all the work while we realize the same benefit without any contribution. With this in mind, I am always impressed with the time and effort people invest in creating, improving, and teaching open source products. The only explanation I have is that other human characteristics (personal pride, love of challenge, sense of accomplishment, satisfaction from helping others, etc.) come to play and override selfish interests enough to lead to these various types of open source contributions.


Conclusion

While the blog post Reasons for Incompetent Developers in India focuses on possible explanations for a certain percentage of incompetent developers in India, the underlying causes are not unique to Indians, but are part of our human nature. The degree that these are manifest may be different between two areas because of various forces at work (economy, labor supply, etc.), but the underlying principles are part of our shared human nature.

Even the existence of the post is a demonstration of contemporary human thinking. Only an Indian software developer could write the things that were written in this blog post on Indian software development without far more controversy. There are many reasons for this, but it is certainly far more difficult to argue with someone "on the inside" who has practical experience with what he or she is writing about. We seemingly can say derogatory things about our own nationality, culture, gender, race, or other demographic, but it is generally deemed unacceptable to say that about another demographic. It kind of reminds me of the concept of "You better not mess with my brother; that's my job."

I don't know much about the state of software development in India, but I have no reason to doubt that what this blog post author wrote is accurate for a certain percentage of Indian developers because I have seen many of the same explanations nicely fit the few truly incompetent developers that I have worked with (and I've never worked in India).

Viral Bad Code: Why and What to Do About It

In the Code Anthem blog post Bad Code is Viral, Amber Shah describes why "writing bad code is viral." This is a great post that reminds me of a pattern I have seen repeatedly: bad code does seem to have a viral nature. Even when the original bad code is rooted out, it is often removed too late and the infection has spread into other pieces of the code. In this post, I look at some of the observations I have made regarding bad viral code and how to contain it and eradicate it.


Why Bad Code is So Viral

There are many reasons why bad code is so infectious and viral. I discuss some of these reasons here. It is often true that code approaches, good or bad, are copied and imitated. When good approaches spread, it's a best practice; when bad approaches spread, it's a virus.


Bad Practices Can Be Learned

The Code Anthem blog post I cited at the beginning of this post mentions one of the reasons bad code can be so viral: "Your code base is the primary training manual for new developers on your team. If they’re learning from crappy code, that’s how they will write code too." We all learn from writing our own code and reading and maintaining existing code. Especially when we don't know better, it is easy to "pick up" new code approaches without regard to how good or bad they are. With experience, we are more likely to recognize bad ideas when we see them. However, even experienced developers can learn bad habits, especially when learning something new to them.


Bad Code Can Be Justified

Most developers don't intentionally write bad code because they enjoy it. They either don't know better or choose to write bad code because they have justified it to themselves. Justifications we might use for knowingly writing bad code include time constraints, lack of resources, and thoughts of replacing it later when there's more time, etc.


Copy-and-paste "Reuse"

There are many problems associated with Copy-and-paste reuse, not the least of which is the greater likelihood of spreading bad code. Of course, if there is a logic problem with the original code or if the code needs to be changed for any reason, it is likely that the same change needs to be made elsewhere as well. Similarly, even if the bad code is completely cleaned up, its effect may remain long after that because of the copied code.


Bad Code is Often Easiest Initial Code

One of the reasons it is easy to write bad code and even easier to copy and use bad code is because bad code often seems easiest at first. There are certain approaches with code that may seem like a good idea at the time or at least like not a bad idea, but then prove to be disastrous in the long run. This is related to the time constraints discussed above when a developer chooses the easiest way for short-term benefit at the price of long-term detriment.


The First Impression is Not Always Correct

I've heard it said that first impressions are often correct. That's increasingly the case as one gains experience, but it's not always true and it's certainly often not true when one lacks experience in a given area. In our rush to deliver, we sometimes go with our first impression because it's "good enough" and we don't want to "undo" anything we've already designed and implemented. This can become very dysfunctional if we start shoehorning a solution into our original concept even when it doesn't really fit. Another developer can be negatively influenced when he or she sees a poorly implemented solution and it becomes his or her "first impression" as well, blocking out other ideas. There is an interesting twist here: even "good code" in one situation might become "bad code" in a different situation. This is one of the reasons I believe it is good to infuse new blood into a development team to bring in new ideas and break people free from first impressions and "that's the way we've always done it" thinking. Individuals can also gain these benefits from choosing to work with different developers.


Ulterior Motives

I have blogged before about how selfish developers can be a real drag on a project's success when they succumb to dysfunctional motivations. Bad code is just one symptom of this and can easily spread if multiple developers are infected by such motivations.


Afraid to Ask

One of the reasons that bad code is introduced into systems is that the person introducing it doesn't know better. Sometimes, this may be due to a lack of knowledge. If that developer is afraid to ask questions or otherwise chooses to go it alone rather than getting help, he or she is more likely to introduce bad code or to spread bad code. Indeed, this is another case where even code that is considered good in one use is bad when misapplied. Asking the author of the original code why it was "good" might help the developer to understand that a similar approach won't work so well in his or her different situation.



Remedies for Bad Code Viruses

Just as with human health, the best protection against the bad code virus is preventative. The following are some of the ideas the doctor ordered for dealing with viral bad code.


Emphasis on Quality and Craft

I doubt that there will ever be a day where we developers don't need to be as efficient as possible and think we have more time than we need to finish a given project. That being said, it is important to instill the concept of software craftsmanship in ourselves and our fellow developers. Long-term considerations make bad code seem more expensive.


Code Reviews

One of the best ways to stop bad code in its tracks before it can spread is to have experienced developers review each others' code and review less experienced developers' code. It is also helpful to have less experienced developers review experienced developers' code not only to learn from what they're reviewing, but also because even experienced developers make mistakes. Indeed, experienced developers who work together for a long time might learn from each other and reinforce each others' bad habits and a less experienced developer might have a fresh perspective. Code reviews may not be my favorite part of the job, but they can be highly valuable.


Maintain Own and Others' Code

I've heard some very experienced developers state that all new developers should be required to maintain large software code bases for at least one year before being let loose to develop new code. Although this would be difficult for many of us to stomach, I do think there's some wisdom in it. I have probably learned as much or more about what makes good code from maintaining my own code (good and not so good) than I have from writing new code. Writing new code helps a developer learn how to be initially productive and solve an initial problem, but code maintenance helps the developer learn to how to write quality code that stands the test of time. Many positive features of software such as extensibility, flexibility, encapsulation, layering, and so forth are far more obvious during maintenance than during initial development. For me, there's no question that the best developers are those who understand the pain of those who will someday be maintaining their code (may be themselves they are helping).


Read and Apply Lessons Learned and Best Practices

Over the years, Josh Bloch's Effective Java has continually improved as a reference for how to write effective Java code. It's amazing that a book with only two editions can change so much, but the more I work with Java, the better that book gets. Books such as Effective Java (there are similar books for many programming languages) provide good ideas on how to write better code and how to recognize existing bad code.


Use The Code Before Committing It

Some code is most easily recognized as "bad" when one tries to use it. Unit tests can help with this as a built-in mechanism for using the code. If the unit tests are difficult to write to use the code, it is likely a problem with the code that will frustrate other users of that code as well. I often wish developers would use their own APIs first before releasing them onto others. If a piece of code seems "okay" or "good enough," an appropriate question might be, "But would I want to use this or call this?"


Be Wary of Comments Hiding Stinky Code

As with most software development controversies, I find that the two extremes (don't write any comments and comment everything profusely) are too extreme for practical large-scale projects. Instead, the best answer lies somewhere between the extremes and where it falls depends on the problem at hand, the language being used, and so forth. Although I think some comments are appropriate, too many comments are often indicate of bad code. It has been said that "comments are the deodorant for stinky code." If it takes many lines of comments to explain relatively few lines of code, there's a good chance that the code is very stinky. In such cases, this code should be refactored or improved so that code speaks better for itself and to prevent the bad code (with or without the comments) from being applied elsewhere in the system.


Mix It Up

All of the above recommendations can be effective in terms of reducing introduction of bad code and reducing and hindering its spread. However, these practices are most effective when used together. For example, reading quality references such as Effective Java is a useful activity, but reinforcing those concepts with practice in terms of development and maintenance makes it more likely that the principles will be understood and remembered.


Conclusion

Good and bad coding techniques tend get copied and to spread. We welcome the spread of best practices and fret over the spread of dysfunctional practices. The problem is that we don't always know how to differentiate between the two. This post has attempted to cover some of the most common reasons for the rapid spreading of bad code and has also outlined some effective practices for reducing the entry of bad code into our system and hindering its spread.

Online Resources: Android Development, Future of Java, Careers in Software Development

This was another week in which I ran across several blog posts and articles that I thought was particularly interesting and relevant. In this post, I reference these and quickly add my own thoughts on the various subjects. The topics covered by these posts I am referencing are quite diverse, but some common themes do underlie most of them. The individual topics covered include Android development, more on the future of Java, some "current Java" posts, and some insightful posts of software development career development.


Android Development

I recently upgraded to a Droid and have been more interested in Android ever since. There were several reasons for me choosing Droid, one of which was its Android SDK and the ability to leverage my Java experience in Android development as a hobby.

There have been several recent interesting posts on Android development. Besides the obvious sources of information on Android development such as the Android Developers site (including SDK information, The Developer's Guide, the SDK API/Reference, and the Android Developers Blog), there are nice community-oriented sites as well. Android Development Matters is one such site where various articles, posts, and forum messages related to Android development are all collected in one location.

Tim Bray is a prolific blogger and having him on the Android team has led to an influx of Android-related information. For example, his latest post on the Android Developers Blog is called Be Careful with Content Providers and warns Android developers to use undocumented content providers to learn from, but to not base their applications on these. Based on his comments, these undocumented content providers sound similar to classes and packages that Sun included in its Java SDK releases to get things done internally, but did not want developers using directly. Like these Sun examples, the Android internal content providers could change or be dropped at any time.

Although I partially selected Droid because of my interest in creating Android applications at a hobbyist level and although I purchased a book on Android development, I haven't actually started developing my first Android application yet. This in mind, it was nice to read a very quick summary of what one does to create an Android application in Team Pi's A Step-by-Step Guide to Write Your Own Android App. That extremely concise summary boils down the essence of writing an Android application, but for just a little more investment of time, one can go to the original source of this information referenced at the end of the post: How to Write Your First Google Android Application. Of course, the Android Developers Guide section on Application Fundamentals has provides nice introductory information.

In Is the Android truly open source?, Amy Vernon acknowledges that Android "is indeed more open than the iPhone," but is then critical Google for not being as open to outside decisions as they could be. I'm not sure if the author realizes that some of the most successful open source projects have been this way for some time now. SpringSource heavily controls the vision and future of the open source Spring Framework and Sun heavily controlled the decisions related to open source projects such as GlassFish, NetBeans, and so forth. IBM has had similar influence in the earlier years of Eclipse development. Other examples include Google's support of several projects including the Google Web Toolkit and Adobe's sponsoring and guidance of Flex. Even the Apache Software Foundation provides similar guidance and vision for its projects.

Most of us like to think of open source projects as being more than just source that we can view and possibly modify for our own needs. We like to think of the community providing input and coming up with the best results. This has even worked well in some limited cases. However, many of the successful open source projects (including those I just mentioned) seem to have benefited from a single vision of a controlling organization (be that SpringSource, Sun, IBM, Oracle, Apache Software Foundation, etc.). In even more practical terms, organizations like SpringSource and Sun have contributed substantial resources to these projects. Without these contributions, these projects would be nowhere near where they are today. Most of us know the disaster that often follows "designed by committee" (EJB 1.x and 2.x are great examples) and having a single guide for an open source project seems to be a common characteristic of many successful open source projects.

Although I believe that Vernon unfairly minimizes (even as she acknowledges its existence) the gap in "openness" between Android and iPhone, I think one of her statements is particularly important for all developers to remember: "I'm not a developer, so as long as the phone does what I want/need it to, I'm good with it." Too many developers waste time and creative energy arguing over the merits of their favorite operating system, their favorite web browser, their favorite RIA technology (Flash versus HTML5 and Apple versus Flash being among the latest rounds), etc. The sometimes difficult to swallow fact of the matter is that developers' preferences are secondary to the preferences of end users and clients. They don't care how it's implemented as long as it does what they want. No matter how cool or nice a new technology is, it won't necessarily win unless it brings noticeable value to the end user. In Android's case, the end user still typically doesn't care that the development behind Android is more open than it is behind iPhone. However, this difference in openness may ultimately help Android in the sense that more developers will be willing to build their ideas into viable applications on a more open system.


More on the Future of Java

A week ago, I posted a similar post to this one in which I referenced and discussed several posts from the blogosphere that were of particular interest to me. Many of these were related to discussions about the "future of Java." Just after posting that collection, I ran into the insightful post "Java Post Mortem with Gilad Bracha" that summarized two presentations by Bracha at JAX.de 2010. I like this post for a couple reasons. First, it is a nice summary and analysis of Bracha's main points. Second, I think the points are insightful. These include points such as "Java is going to stay but it is going to stay where you don’t want to look" and "Complicated is not a sign that you’re clever. It is a sign that you failed." This summary is well articulated and worth the small investment of time required to read it.

Joseph D. Darcy posted Project Coin: Multi-catch and final Rethrow, a post that looks at the exception handling improvements coming to JDK 7. Based on the comments on this post, the "final" portion seems the most confusing and controversial. Darcy's current (most recent post as of this writing) is Draft of Restarted "OpenJDK Developers' Guide" available for discussion and is specific to JDK 7 as well.

Jens Schauder's post The Question Isn't What is Going on at Oracle and Sun outlines some warning signs to watch for that indicate "that Java is turning into just another kind of COBOL." Schauder points out some ways to transition to other languages when it is time to actively move to languages other than Java if you have not done so already.

Back to Today's Java

Although reading about the future features of Java can be exciting, it is often more practical to learn about what we can do today and to learn from each others' experiences. Along these lines, I found the post How we solved – GC every 1 minute on Tomcat to be interesting. In this post, Sumit Pal discusses the non-standard -XX:+DisableExplicitGC option for the HotSpot JVM. The reader feedback is helpful and adds some background details as well. When I blogged that more developers should write blogs, this was the type of post I had in mind.

In Annotation or Not, the post's author enters the debate regarding when it is appropriate to use and not to use Java annotations. I think most of us welcome annotations to a certain degree and the main part of the controversy now seems to surround what is appropriate for annotations and what is not appropriate for annotations. As I discussed in the article Basic JPA Best Practices, I like how JPA allows you to use annotations but override them via external (XML) configuration as needed.


Software Development Career Development

There were two online resources this past week that I thought were particularly thought-provoking in the area of career development for software developers. In the post 10 Ways to Suck at Programming, Donnie Garvich documents ten things that "are really just things that every good programmer should already know to avoid." Among these ten things, a few of my favorites are "Never, ever remove functionality," "Document NOTHING," and "Catch all errors -- and do nothing with them." These and several others on his list were all too familiar for me (because of others' misbehaviors, of course). As with many of the best posts, the reader comments and feedback messages were also generally useful and interesting and included some additional items that could have made this list.

I have blogged before about my appreciation for posts that require the poster to sacrifice personal pride to provide a lesson from which we all benefit. This happened for me this week in the reddit programming post called I am now practically unemployable by everything I read. Any advice? Although this is somewhat anonymous (its author is unemployed58), it is still admirable that this author was willing to lay some personal career details out there. This post is a reminder that software developers need to stay current. It's a little frightening, though, that this author has stayed current to a degree, at least at the hobbyist level, but has still found himself unemployed for two years.

I often think developers waste a lot of time chasing fads because of dysfunctional motivators such as resume-driven development, the magpie effect, and so on, but this post is a reminder that there are problems on the other end (never doing anything new or different) as well. The post's author ends with, "I apologize for the rant just feeling a little frustrated today." I don't think there's any need for an apology. In fact, I appreciate the fact that this was posted and can be a reminder for all of us. Some of the feedback comments on this post are also useful in terms of ideas for the original poster that might work for all of us to reduce the chance of ending up in that situation and to deal with that if/when it does occur.

In Programmer Tip: Work Less, Stay Focused And Say No To Random Meaningless Slogging, Rajiv Popat points out the need for most developers to creatively solve problems in reasonable amounts of time rather than slogging away for 14 hour days (perhaps a dialect of presenteeism?).


Conclusion

I cannot come even close to reading all the content related to software development that comes out online each week that looks interesting to me. However, the resources that I referenced in this post are ones that managed to grab my attention amid the noise and bustle of the blogosphere and which I can wholeheartedly recommend for busy developers to invest time in reading if the covered topic is of personal interest.

Poorly Finished Basements in Software Development

Several years ago when I was looking for a house to purchase, I saw several otherwise attractive homes that I decided against purchasing after seeing the badly finished basements. These finished basements were turn-offs for a variety of reasons such as 1970s paneling and/or carpet, cheap materials, bad and/or strange layouts, and so forth. An alluring aspect of purchasing a new house can be the chance to have the basement finished exactly as one would want it. When the basement is already finished, it may be less like what one would want. It is more work to fix the existing finished basement by tearing things down and rebuilding than it would have been to build it in the first place. Of course, there is the relatively rare situation when one is fortunate enough to find a nicely finished basement that is close to or exactly what one wants. This can be preferred even over an unfinished basement because the work is already done, done well, and satisfies the desires of the purchaser.

Working on software development projects can sometimes feel like buying a house. The unfinished basement is like a greenfield project where anything is still possible, but will require effort and skill to accomplish grand visions. The poorly finished basement is like a badly written piece of software that is difficult to read and maintain. Just as even a reasonably nicely finished basement may not offer a potential home buyer what he or she wants in a basement, a relatively well-done piece of software may not meet customer expectations of certain features (and more likely will suffer some Not Invented Here Syndrome effects from developers). On the other hand, in a relatively small percentage of cases, customers and developers may find that the existing code being reused is so well done that they don't feel the need to refactor it. In these cases, the software is extremely valuable for its features and quality.

My realtor pointed out that certain features of a finished basement are easier to change than others. For example, it is easier to put in new floor coverings (carpet, tile, hard wood flooring, etc.) and to paint than it is to change layout (changing plumbing location or locations of walls). The use of existing software is similar. Some aspects of maintaining and reusing existing software are easier to improve than others. For example, it is generally easier to improve the names of variables, method names, and other structures than it is to make significant architectural and design changes. In both software development and house buying decisions, it is important to realize that not all problems with existing product are of the same difficulty to improve. Just as one might buy a house with a finished basement of reasonable layout but outdated carpet and paint, it is often worth the time and effort to improve the "little things" that make existing code less maintainable than it otherwise might be.

There are times when one buys a house with a really badly finished basement because there aren't many other choices. For example, the location of the house of the rest of the house may be so attractive that the buyer feels the deal is worth taking even with the poorly finished basement. Similarly, we run into situations in software development where we must deal with and improve badly crafted software because the features of the existing software are too compelling to ignore. Reasons for this could include the high cost of completely rewriting the software, the inability to completely rebuild the software, and so on.

The worst basements that I saw were the ones that had crazy, maze-like layouts as if the basement was built without any planning or design. The worst software feels very much the same. When I saw the worst of the finished basements, I realized that I'd probably end up tearing down large portions of the finished basements to rebuild them in an improved fashion. The worst software is similar in the sense that it too often must be completely torn down and rebuilt if it is too badly implemented.

The other side of this discussion is what we can do as the sellers of the house or developers of the original software to make our products more interesting to potential buyers and developers. As a home owner, we can spend time and resources to carefully design a generally appealing and useful basement that adds value to the house rather than detracting from that value. Similarly, in software, careful design and forethought can lead to better planned and more readable software. With both basements and software, we also need to be prepared to undo (refactor) some of our work if we realize we have made a mistake. For example, the homeowners with the maze-like basements should probably have been more willing to tear down and change walls to have a more useful and desirable basement.

One of the characteristics of some of the unappealing basements I saw was the inclusion of specialty features that I was not interested in. Undesirable features clouded my vision of how the basement might be used and, at best, were seen as something that would have to be tolerated or removed with additional effort. Similarly in software, we can make our code more attractive to those who wish to maintain and reuse it by using established practices, avoiding being too clever, and adding producing code that is generally pleasing.

A poorly finished basement can turn away even the most interested potential buyer. Similarly, poorly implemented code can turn away the most enthusiastic software developer. Most software developers I know prefer to work on completely new projects. However, a close second is to add to or enhance a well-written existing code base. It is usually far less exciting to try to band-aid a poorly written piece of code and it is often very tempting to tear it down altogether and start over. However, just as it is for the homeowner who tears down and rebuilds a basement, this is both expensive and time-consuming.

Interesting Software Development Tidbits - Early May 2010

In this blog post, I summarize and reference some recent software development blog posts that I have found to be particularly interesting. These cover subjects such as the future of Java, the need for developers to have database skills, locating Java class files used in an application, Java sorting algorithms, and anticipated new Java dynamic language support on the JVM.

Future of Java: 2010

Most of us have read countless articles and blogs predicting what the future holds for Java and for Java developers. The recent Oracle acquisition of Sun Microsystems has renewed and even increased the desire to know what's in store for Java. There are a couple recent online resources covering opinions of some Java community members regarding Java's future that are particularly interesting.

A Discussion with Josh Bloch on the Future of Java

A Discussion with Josh Bloch on the Future of Java features one of the best-known names in the world of Java. The author of Effective Java and a large portion of the Java Collections Framework approaches the future of Java from a very practical, enterprise-oriented approach. This Josh Long interview of Josh Bloch is a follow-up to a talk Bloch gave at RedHat Middleware 2020 virtual conference and which Long describes as a talk with "guarded optimism and concern about the future of the Java platform under Oracle's stewardship."

I appreciated that this Josh/Josh collaboration was candid (Bloch stated "several factors that have combined in the past few years to take the wind out of Java's sails" and stated one of these primary factors as "Sun's lack of support, leadership, and clarity has kept Java 7 from making perceptible progress"), had an insider perspective ("Sun allocated [few resources] to Java SE in the past few years"), was balanced ("none of these languages [JVM languages other than Java] make Tiobe's top 20. That doesn't mean they aren't important or valuable; they are. But they aren't mainstream, yet"), and was realistic about the future ("With the exception of CLR which is in-practice a Windows-only platform, there's no real alternative to the JVM on the horizon" and "I think there is some danger of a decline, but I'm counting on Oracle and the Java community to prevent it").

Java Platform Roundtable, Spring 2010

Two former JavaWorld editors (Jenni Aloi and Athen O'Shea) collect and organize the thoughts and opinions of "nine leading thinkers in the Java community" (Alex Miller, Neal Ford, Ted Neward, Rick Hightower, Andrew Glover, Steven Perry, Mik Kersten, Dan Allen, and Chris Mackie).

Like Bloch, the panelists in this roundtable mentioned that some of Java's biggest current problems are related to the Java Community Process and licensing issues. Panelists also express concern about the effect on Java-related open source projects. Panelist discussion also covers Java 7 and other aspects of Java's future with specific discussion on closures, modularity and Project Jigsaw, multiple languages on the JVM, Spring Framework, OpenJDK, Apache Harmony, and cloud computing.

What the Heck is Going on at Former Sun Microsystems?

Markus Karg is not nearly as optimistic about the future of Java as either Bloch's or the panelists' "subdued optimism." Karg writes about the numerous departures of long-term Sun employees from Oracle and writes this ominous statement: "In the long term, Oracle will merge every valuable asset (like Java) into a proprietary product, and exterminate the rest. ... Then, there will be only Oracle, but no Java anymore." For people who doubt this, Karg issues this challenge: "Let's meet again in five years if you doubt it."



Developers Still Need Database Skills

This blog post caught my attention because it resonates with my recent post Sqlphobia: The Irrational Fear of SQL. Some of the things that stood out to me regarding this post were its .NET perspective (my post was largely from a Java perspective), its focus on database architecture knowledge as well as the SQL language, and its realistic assessment ("Lets be frank here, no ORM will handle all of you query needs. At best we are talking 90%, sometimes only 80%, for a typical application. At some point you either have to go to the metal, or you end up coding things in a very strange way.").

As a side note, this same blog has a post called Say 'No' to 'Null' that made me think of my blog post Effective Java NullPointerException Handling.



Finding Out Where Your Class Files Are

Axel Rauschmayer's Finding Out Where Your Class Files Are succinctly describes how to use the JDK ProtectionDomain class to find out where the class definition file for a particular class was found. This was not new to me (I blogged about it previously), but I still liked the conciseness in which this handy tip was covered and I really enjoyed the feedback, especially the Artur Biesiadowski reply. That made me laugh because it is all too true. The original post is short and an easy read and the lengthier feedback from Artur Biesiadowski is humorous too.



17 Clean Implementations of Java Sorting Algorithms

I have not looked at or used the algorithms discussed in 17 Clean Implementations of Java Sorting Algorithms, but I do like the idea and think it could be a potentially valuable source of information for Java developers.



Dynamic Java Language Support on the Java Virtual Machine

This article has more detail on upcoming JVM support for dynamic languages than I really need. That being said, I find myself using dynamic languages (especially Groovy) increasingly and it is typically beneficial to know more details about the underlying support than what I need on the surface level. Even for Java developers who may not be using dynamic languages, this article has interesting details regarding Java byte code that could be beneficial to understand better.