Simplifying Software Development, Page 2
Is Java the Problem?
There is a movement gaining popularity right now that Java itself is the problem, and that the only solution is to replace it with something simpler and cleaner.
I am not a complete subscriber to this viewpoint. There are many holes in it, but I understand that there is also some truth to the claims.
Java 5 added some new features, such as the new for loop (which I believe simplifies the language further), autoboxing (which does likewise to help break down some of the confusion between primitives and Object-derived types) and some other features such as generics that are the cause of some debate as to whether they simplify or complicate the language.
It's important to remember that having features in a language does not mean that you have to use them. I land on the side of generics being a benefit, the extra type-safety, and the fact that you don't have to remember to cast everything coming out of a collection are reason enough for me, but if you don't like them, don't use them.
So, at its core Java is still a simple language. Maybe it's a little wordier than some of the slicker scripting languages out there (one of my favorites is Python, and I have known and used it slightly longer than I have used Java), but it's simple enough for anyone serious about learning it to grasp quickly.
No, Java's problem is Java Enterprise Edition (what used to be called J2EE). In fact, even more than that, it's EJBs (most people outside of the Java world still believe EJBs and Java Enterprise Edition are the same thing). Certainly any whitepaper I have ever seen railing against of the complexity of using Java Enterprise Edition bases its case on that.
Beyond that, it's not just EJBs that are complex, but the full on EJB experience. Multiple classes, strict inheritance rules, and XML-based deployment descriptors edited by hand. Yes, that is overly complex (for most things, there are occasions you may be glad that you have the option to interact at that level).
But, let's examine the alternatives to Java, and where they might be useful.
Is Ruby on Rails the answer? How about Groovy? Should we just abandon Java as overcomplicated and past it? That certainly seems to be a popular viewpoint right now, but that answer is going to have to come from you (and likely your company). Despite being a big fan of dynamic languages, I see them as a complement rather than a full alternative.
For example, I have just finished a project that uses Groovy as a fast way of constructing translators (import/export code if you prefer) between file formats and a database. The built-in syntactic and semantic support for XML and SQL was extremely useful and both simplified and sped development. For the rest of the system, however, we used Java, and drew on IDEs to speed and simplify the development there.
There is a lot of interest in Ruby on Rails for rapidly building Web front end/database back end applications right now, and it does make for a very compelling demo. One thing I have noticed, however, is that the comparison is always made to a more traditional approach of Java development, maybe using Entity EJBs, JDO or Hibernate for the persistence layer, and Struts, Tapestry, or similar for the Web front end.
What I have yet to see was a comparison of Ruby on Rails building the same app as a Java stack using the sort of high-level IDEs that are now available for building such apps in Java. To me, a face-off between Ruby on Rails and Java Studio Creator would be far more interesting. Most of the applications I have seen produced in Ruby on Rails demonstrations would only take minutes to construct in Java Studio Creator also, and they both occupy almost exactly the same problem domain.
On top of this, though, with the Java option I have more mature tools for construction and debugging, wysiwyg editing for the Web pages, and many more advantages from a more mature and feature rich tools platform. Those kind of things also speed and simplify development.
I regularly draw on Python, Jython, Groovy, Ruby, and Perl both for personal and work usage, but still Java remains the primary platform for both personal and work usage.
The point I am trying to make is that if you are finding Java development too complex (or any other platform for that matter), the complexity may not lie in the language, but rather in your approach or choice of tools. Examine those before throwing out the baby with the bathwater.
Simplify Your Tools
As you can tell from the above, I think that tools play an important part in whether development is simple or complicated.
Higher level tools can help isolate you from some of the complexity. Regular readers of Developer.com will see that in previous articles, I, and other authors, have demonstrated that Java EE doesn't mean EJBs, and if it does, that EJBs can be made easier.
My favorite approach to doing so is the aggressive use of high-level IDEs that help you manage the complexity. The best of these do not run you through a Q&A wizard and spit out boilerplate code; rather, they integrate those Java EE standards needed into the environment in a way that lets you work with the standards without getting lost in complexity.
A great example of this is Sun's Java Studio Creator. I have been involved from a very early time with this IDE; I was interested when the IDE was still known as Project Rave. The reason I like it so much is that it does what few Java tools are brave enough to do. In other words, it doesn't try and do everything.
Java Studio Creator concentrates on one very focused task: simply and rapidly creating Web-based applications using data stored in a database. This will sound very familiar to anyone who has looked at the problem domain Ruby on Rails is aiming for.
As a bonus, Java Studio Creator can also consume (in other words, be a client for) Web Services and EJBs. It does so in a similarly simple, straightforward, and fast way. It cannot create EJBs or Web Services (at least it does not offer you any assistance at all in doing so), but it makes client apps for these systems very easy to construct.
I am delighted to see that Sun, Oracle, and others are starting to do the same with many of their development tools at present. Oracle's recent versions of JDeveloper try and limit the complexity by trying to tailor the IDE to the type of project you are developing, and not overwhelming you with choices. Sun's NetBeans 5.0 is concentrating on simplifying EJB and Java EE development through the use of high level integration removing you from having to write or edit any of the XML configuration files. On top of that, their new Matisse GUI builder is exactly the way things should be going (finally, a really easy and productive Swing GUI builder). I am not a GUI guy, so the easier and quicker I can throw a GUI together, the quicker I can concentrate on the real development work.
As an aside, just recently I had the benefit of helping a good friend get a new start using Java after many years of C/C++. It had been a long time since I had looked at the Java world through a beginner's eyes, and watching his stumbling points was a rare opportunity to make some observations about the problems of getting started.
He started using Eclipse, a natural enough choice because it is the most widely used IDE for Java, and immediately got lost in its myriad of options from the start. Having started with the Eclipse IDE from the viewpoint of already knowing Java well, I knew that it was a powerful IDE that could do everything I wanted. The problem was that it never occurred to me how alien or overwhelming it might be for someone new to the whole field.
Another thing that bit him early was the lack of built-in support for GUI building and easy EJB construction. Although EJBs in particular are an advanced subject, it was clear that he would need to understand them before building the large system his company was planning. Selecting and downloading plugins for EJBs and GUI development was extra time and complexity.
Be an Engineer, not a Reference Book
I once heard a story that Albert Einstein refused to learn his own telephone number, saying that he would not clutter up his brain with information that could be retrieved from a book.
I don't know whether the story is true, and I suspect that it isn't, but it is still a great story with a good moral. If you have a limited amount of time, it is better to spend it on understanding the problem than understanding the tools and language inside out.
I don't mean to put anyone off of learning about a language or tool. If that floats your boat, then obviously knowing both the problem domain and the language and tools thoroughly well make you a more effective engineer. But if time forces you to choose, choose understanding the problem domain thoroughly, and pick the rest up from books as you go.
Worried About Outsourcing?
By sticking to the core tasks, those that bring direct value to you or your company, those that you were hired to do, what is there to be outsourced? Persistence layers and hundreds of JSP pages are ripe for being outsourced, but if you are able to construct these things yourself very quickly and simply, then get back to concentrating on the real value add, what's to be outsourced?
Experience the Speed
I have no real interest in GUI construction, Object Relational mapping, and other commonplace tasks. I am very interested in tools that let me do them and get them out of the way as quickly and as simply as possible, because that lets me get back to the real work.
Choose Your Battles
Of course, you can't simplify everything to the point of absurdity. There are some things that are not already done, things that add real value. These are the ones that you should be concentrating on. If you want to drop out of complexity altogether, software development probably isn't the right field for you. Choose your battles, concentrate on those problems you can really bring value to, and for the rest, re-use whatever you can.
This was a difficult article to write. There is so much more I would like to have said, so many areas where I would have liked to have backed up what I said more, but the article was already long.
Suffice to say that the material presented here represents my best knowledge about simplifying the development process at present. It may change in the future (I hope it does; such things should always be evolving as you learn more).
I believe that complexity is often a problem of our own manufacture. It is easy to blame the language, the requirements, or any one of a number of other sources, but the truth is that it is usually process and approach that cause complexity.
A language does not automatically make development complex. Anything can be coded simply in any language (even Perl).
Libraries likewise do not automatically make things complex. In fact, this is an easy one to dispel. If a library is causing your complexity, don't use it.
Stick to what is core. The more you can hand off outlying tasks to third parties, open source or commercial components, to concentrate on the core of your task, the faster and simpler your development will be (and the less likely to be outsourced).
If a few requirements are causing much more complexity, go back and re-examine whether they are really necessary. Think of creative ways to work around them to try and allow you to use ready components instead of having to write your own.
Try and be an engineer instead of a reference book. You can buy reference books and keep them on hand, ready for use. It is far better to have a good understanding of the system you are constructing than an intricate knowledge of the language and tools you are constructing it with, especially when the language and tools come with manuals, and usually the system does not.
Keep looking at new tools and options. It still appears that frameworks such as JSF and JDBC Rowsets, and tools like Java Studio Creator are relatively unknown for reducing complexity.
And finally—never run a mail server at home when gmail will do everything you need and more.
A future article will cover more details about the process that we voluntarily implemented at my company in an effort to manage the increasing complexity.
About the Author
Dick Wall is a Lead Systems Engineer for NewEnergy Associates, A Siemens Company based in Atlanta, GA that provides energy IT and consulting solutions for decision support and energy operations. He can be reached for comment on this and other matters at firstname.lastname@example.org. He also co-hosts the Java Posse with Tor Norbye and Carl Quinn, a podcast devoted to Java News and Interviews, which can be found at http://javaposse.com.
Page 2 of 2