New Year RAM Dump
by John W. Stout

This is the time of year when people reflect on events of the preceding twelve months and contemplate what lies ahead in the New Year. Here are a few of my random thoughts.

In southeast Michigan, which is the location of our headquarters and center of our customer base, it’s mostly bad news in the media about the current and future state of the auto industry. While I can’t comment on how much of what we read about these things is factual, one thing is clear - the automakers and their top suppliers need to hire better public relations people!

Baby Boomers (which includes me and many of our readers) will start retiring or moving off full-time employment in droves over the next ten years. The rising average age of the American software engineer is, within those same few years, going to be responsible for notable labor shortages in the IT industry. The pinch is already being felt in some areas. Adding fuel to the fire, fewer young people are choosing Computer Science as a career - 39% fewer than five years ago. This creates the ironic image of an industry - which in recent memory was the domain of "kids" - soon to be dominated by middle aged (and older) folks. The term "Senior Software Engineer" takes on a whole new meaning!

The well-publicized failure of many attempts to offshore IT projects would seem to indicate that foreign labor is no longer the vast universal threat that it once appeared to the U.S. IT industry. In the experience of our staff and clients, the types of projects that have succeeded best offshore are repetitive tasks, as opposed to the kind of work that requires in-depth U.S. cultural experience or significant requirements-gathering and architectural work. I’ll qualify that by saying I am also sure that there are plenty of exceptions and that my offshoring colleagues will have some other thoughts about it. One other development: for better or worse, almost every state in the union has introduced bills to prevent or reduce the offshoring of U.S. jobs.

My random thoughts wouldn’t be complete without some technology items. I have commented before on the somewhat rising prominence of Java and diminishing importance of C++ as the development language of choice. We see this in the demand for software engineering professionals. One of things that has held Java back in the past is the lower quality of development tools as compared to their counterparts in the C and C++ world.

That’s changed.

Earlier this year, Infoworld reviewed several Java Integrated Development Environments (IDEs) and discovered a number of features that exceed those in corresponding C/C++ tools. Our colleagues concur.

One of the other factors making C++ less attractive for developing large scale applications is that it is fraught with peril from such things as pointer and memory bugs, memory leaks, and loads of obscure ways to shoot yourself in the foot - generally a higher level of complexity to implement bug-free solutions. C# is Microsoft’s answer and .NET has attained dominance in companies that use Microsoft technology for their applications. And .NET is similar to Java in many aspects, particularly those that reduce the complexity of development. I am not saying that C++ is archaic or useless, just reporting that it will be used less and less for application development from here on out.

Speaking of .NET, .NET 2.0 is an important evolution. Besides easier deployment, it’s also faster. Performance is one area where .NET competes very well with Java.

Have a happy and prosperous New Year!

John W. Stout is the founder and president of Stout Systems. He has twenty-five years experience in the software industry. He is also sought after as a technology speaker, presenting sessions at developer conferences and user groups. E-mail .

-back to top-

---

A Business Case for the Spring Framework
by Dan Rudman

In that last edition of this newsletter in an article titled, Externalizing Enterprise Configuration with the Spring Framework, I extolled the technical virtues of building configurable applications with the Spring framework.

The job of an architect is frequently complicated by the need to make solid business choices rather than what sounds technically interesting at the moment. Therefore, this article will focus on why the business folks should be happy you’ve chosen to use the Spring Framework on your next project.

J2EE implementations are, quite honestly, not always the picture of great success. While J2EE brought us a much-needed standardization to concepts like transaction management, the simple truth is that J2EE applications are overly complicated, require excessive resources and effort to develop, and frequently produce less than stellar performance. More specifically:

• J2EE applications tend to have too much "glue". Many applications I have worked on over the years contain a disproportionate amount of code that provides no useful business function. Transfer Objects, Factories, and excessive try/catch blocks are all examples of "wasted code". Wasted code is a waste of time and money for businesses.
  
• J2EE applications create undue challenges to unit testing. The design of J2EE APIs (most notably, the EJB model) does not provide consideration for unit testing development. Without an application server and all of the associated resources in place and fully configured, it can be incredibly difficult to unit test application code that uses EJBs (or many other J2EE APIs for that matter). Since unit testing provides you the fastest and cheapest mechanism for preventing costly rework and user-angering production issues, this is a hot item for architects – and thus for businesses.
  
• The EJB model is unnecessarily complex and forces developers to either use or work around a distributed object model. EJBs were designed for internally distributed, transactional applications. When the application you are building distributes its components externally or doesn’t distribute its components at all, use of EJBs can create a burden on architects and developers. The need to work around the distribution model creates risk and time expansion to a project. While nearly all enterprise applications are indeed transactional, it is undesirable to forcefully integrate the distributed aspect right into the component model.

The Spring Framework was designed from the ground up to address these issues. And while Spring is by no means perfect, it does provide a number of business-impacting benefits:

• Spring reduces "glue". Using the principle of Inversion of Control (IoC) / Dependency Injection, Spring replaces the patterns that produce much of the wasted plumbing code with one which does not. IoC / Dependency Injection is a pattern that produces loose coupling between objects and promotes reuse. Essentially, you don’t create your objects – instead, you describe how they should be created. You don’t directly connect your components and services together in code – instead, you describe which services are needed by which components, and the container is responsible for hooking it all together. The container creates all the objects, wires them together by setting the necessary properties, and determines when methods are invoked. Thus, your development team ends up working more on code that is meaningful to your business and spends less time fighting with the architecture to make all of the pieces work together.
  
• Spring is designed for application testability. Spring applications typically consist of Plain Old Java Objects (POJOs) – which are by nature extremely easy to test. Dependencies on Spring will typically be to interfaces rather than extended classes, which makes them easy to stub out or mock.
  
• Spring allows architectural choices. The framework is designed so it can be replaced at any layer. With the simple change of a configuration value, a team should be able to switch from one component framework to another – for example, from Hibernate to Ibatis, or from Struts to WebWork – with no impact on the code. This flexibility means your architectural decisions do not need to be written in stone and can be changed later in the project – something that would likely sink a project written without Spring.
  
• Spring is not an integral part of the application by design. Contrary to EJBs, the entire framework is designed around an intentional goal of being replaceable. While some lock-in may not be avoidable altogether, Spring minimizes the places where this can happen. This gives your business freedom to act swiftly to changing needs.
  
• Spring facilitates good design practices. Spring causes developers to design to interfaces, which promotes swappable components and the design of objects as services rather than giant function repositories. In addition, Spring’s IoC frequently results in easier to read business logic because the "glue" is reduced or removed. That means lower maintenance costs.·
  
• Spring simplifies configuration. As discussed in my previous article, Spring encourages designs that move configuration out of Java code and into externalized files. This means more configurable code – and that usually translates to more maintainable and reusable code.

In short, Spring’s design avoids many of the pitfalls produced in the typical J2EE application. With its popularity soaring and its lack of lock-in, the benefits Spring provides to a business are hard to ignore. On your next project, have your architect look seriously at Spring - it could have a very meaningful impact on your business.

Dan Rudman is the President of Kade Consulting, LLC and a specialist in enterprise Java architecture with a decade of Java experience.  He is a postgraduate of the University of Michigan in Ann Arbor and a perpetual student of everything.

 -back to top-