Have you had this experience with technical professionals who say something like this?: "Well I built a whole application at company X using technologies XYZ and leading X number of developers. You should have seen it, that application was beautiful and still runs X users today."

I myself have done tons of development including COBOL, ColdFusion, XML/XSLT, JSP/servlet, Struts, and J2EE. I can build an enterprise Java application from the ground up using technologies like JSP, Struts, EJBs, iBatis, and WebLogic...but is that good enough in today's market? Bringing these old skills to my current job definitely helped me be a stronger developer, but I was definitely missing something valuable. I was missing the strategies and methodologies that were revolutionizing and shaping the industry such as the emergence and success of IOC frameworks, persistence frameworks, POJO concepts, Web 2.0 impact, SOA, and scripting languages.

Not understanding these concepts and how and why the industry changed was causing me to bring my outdated methodologies to the table as a way to provide outdated solutions. According to these changes in the industry, I was not totally relevant; capable, but not relevant. But if I can develop J2EE enterprise applications, I have to ask myself, do I need to stay relevant?

Do We Need To Be Relevant?
In sports and athletics, many athletes reach a point in their careers where they can't run any faster, jump any higher, or hit any stronger, and that's when they hit their peak. Sometimes reaching that peak is voluntary and sometimes involuntary. I reached that peak in swimming before I could take that competitive sportsmanship to a higher level like college. But in the IT industry, an individual has to ensure that they never reach their peak because the evolution of technology grows and reshapes itself so rapidly that there's no time to claim that we know all there is to know. I asked myself this question and thought I should evaluate some of the trends that have occurred in the industry. Just as an example, Figure 1 is a timeline of technologies and their estimated start dates, first release dates, or estimated dates of usage.

Now I needed to take what I compiled in this timeline to try to determine if I needed to be relevant, and figure out if relevance means that I have to be current. Looking at some of the dates it seems absolutely amazing how many innovations occurred in such a short window of time, and as each year progressed, how more significant and massive changes sent bigger tidal waves through the industry. The emergence of SOA as a methodology shows this with its ripple effects of products developed and designed to support its promise for interoperability to all who use its concepts. Then the emergence of Web 2.0 blows the others away with its continual creation of buzzwords, websites, and new widget kits. These sweeping innovations bring new concepts, new methodologies, and new technologies.

Now let's add a developer's career path in IT to this timeline by assuming it might include promotions to technical lead and manager. Now this does not represent by default that the individual loses his relevance when attaining these positions, but we should be aware that the positions' new job requirements limit one's ability to stay abreast of technical trends. I have been through a few management interviews to know that even IT managers are expected to let go of the technical aspects of development and architecture and focus on developing a successful IT group as well as meeting business needs.

Taking a look at Figure 2 and comparing it to a developer's career path, we can begin to comprehend what happens when a developer (who is technically relevant) becomes a manager (let's say at the beginning of 2005). If that manager is trying to play a technical role and isn't delegating technical decisions to developers with the relevant skills, he can't be properly informed about some of the evolving technologies such as EJB 3.0, Struts 2, AXIOM, XQuery, Google Web Toolkit, Grails, XQuery, or JPA. These technologies and the concepts that drive them have transformed and redefined the way we develop enterprise applications with J2EE through new methodologies and concepts such as dependency injection, POJOs, persistence frameworks, Web frameworks, XML parsers, SOA, and Web 2.0. By understanding these technologies and their needs, we can better understand the transitions from previous technologies to the technologies that exist today.

When talking about being relevant, we need to determine if being relevant is the same as being current. I believe that being current with today's technologies absolutely drives us to be relevant. Many times, being current is discouraged because of labels like "bleeding edge." But methodologies aren't "bleeding edge"; the implementation of those methodologies can be "bleeding edge" like APIs and frameworks. The problem is that it's still important to understand the focus and purpose of these APIs and frameworks to be able to defend or question the way we do development.

For instance, when the Spring Framework came out, many of the J2EE developers and managers that I interacted with called the framework too "bleeding edge," but they were either referring to the API or the fact that they knew nothing about the Spring Framework and so it was easy to label it "bleeding edge." Many of the concepts and issues addressed in Rod Johnson's books called Expert One-on-One J2EE Development without EJB and Expert One-on-One J2EE Design and Development were not "bleeding edge." Topics discussed like object-relational impedance mismatch, container dependencies, testing complexity, object coupling, and separation of concerns weren't "bleeding edge," but very relevant to understanding what J2EE was leaking into our architecture and where it needed to go to become more successful as a specification. Both responded with the rising success of the Spring Framework and the introduction of EJB 3.0, as well as concepts such as dependency injection, AOP, and POJOs. We absolutely need to be relevant and current.