It’s time to move on and show the simple elegance Spring brings to OSGi development using the HelloWorldSpec sample from the OSGi & Modularity post. But first, a little primer on Spring Dynamic Modules. Spring DM is not an OSGi implementation. Instead, Spring DM aims to make working with OSGi easier just as Spring makes the world of Enterprise Java simpler. One of the more striking characteristics of Spring DM is that it removes most your code’s dependencies on OSGi by taking care of the OSGi plumbing. To function in an OSGi runtime environment, the Spring .jars have been packaged as OSGi bundles.

Read more

Software failure statistics are abundant and serve as clear evidence that we must reform software development. While industry claims an IT labor shortage is the motivating force behind outsourcing, the greatest factor is directly related to our inability to deliver value-add software. As organizations continue to lose faith in IT as a trusted partner, the services we offer are little more than an ample commodity, and the search for cheaper labor will persist. But, there is no IT labor shortage.

Read more

The .jar file has always been a great unit of modularity on the Java platform. Unfortunately, it also comes with the classpath baggage, and .jar files were never treated as first class components. OSGi is the next generation component platform that will bring greater modularity to the Java platform. In my previous blog, I showed the simplest OSGi components imaginable. Now I want to expand on that slightly by introducing a third component that exposes a key architectural and design benefit enabled by OSGi.

Read more

Lately, I’ve been experimenting more with OSGi, and I want to share some of the examples I’ve put together. The examples involve Felix, Spring Dynamic Modules, and Jetty, though could easily be used with Equinox. Once I’m finished with these exercises, I’m hoping to compare and contrast the different approaches I’ve taken, as well as comparing embedded Jetty with the Equinox Servlet Bridge. I’m a believer that OSGi is a disruptive technology that stands to transform Java development as we know it today.

Read more

Some of you may have seen this video explaining the placement of phony job ads that are subsequently used to prove to the Department of Labor that there is an IT labor shortage. Lou Dobbs also got in on the mix as shown in this YouTube video, or take a look at the transcript. This ammunition is used to secure green cards for H-1B Visa workers. It’s repulsive. Bottom line - there is no IT labor shortage.

Here are some more numbers from the Dobbs video. Universities are pumping out over 300,000 bachelors, masters, or PhD degrees annually in computer or information science, math, and engineering. The Department of Labor predicts the average yearly job creation in those fields to be 120,000 jobs.

I’m a believer in competition, but it must be fair. Data suggests that on average, H-1B Visa Holders are paid between $12,500 and $20,000 less than their American counterparts. I’m not anti-H-1B. I’ve worked with a large share of very good developers who were H-1B visa holders. Unfortunately, the H-1B visa program is being used to replace the jobs of U.S. IT professionals with cheaper labor.

A two pronged approach is required to fix the problem and requires a professional code of conduct between employees and employers. The result is a win-win-win situation for all involved. First, we need not eliminate or minimize the H-1B visa program, but instead must bring the salaries of visa holders up to levels equal to that of their American peers. Second, we must reform IT through incremental delivery of quality software. Until these happen, U.S. citizens will continue to suffer job loss due to anti-competitive and fraudulent practices.

There is no IT labor shortage in the U.S. There is no dearth of software developers. Instead, this shortage is reinforced through repetitious pronouncements by industry of the impending labor crisis, and is used as outsourcing ammunition. In reality, organizations outsource because of two simple and related factors:

• Business believes IT costs are too high and by outsourcing IT labor, cost is reduced.
• IT doesn’t deliver value-add business software.

Read more

March 31st marks my first day as an Analyst with Burton Group working in the Application Platform Strategies group. To an extent, this is a career change for me. Since I’ve been in IT, I’ve worked exclusively on enterprise development projects. Over the years, I’ve played most roles on the software development team, but my favorite has always been as the guy who gets his hands dirty writing code. Through writing and speaking, I’ve enjoyed sharing these experiences with others. To this point, however, any writing or speaking I’ve done has always been an extracurricular activity, making it feel like I’ve always had two jobs instead of one.

My role as an analyst means I’m no longer a software developer working in the trenches. The reality over the past couple years is that I was working less in the trenches anyway. As I continued to shape and express my software development beliefs, I also began to gravitate more toward leadership roles, though not always intentionally. Whereas I once coded all day every day, I now code only a few hours each week. Instead, I spend more time mentoring developers, evaluating emerging technologies, and guiding teams through the process improvement quagmire. But yes, through it all, I still code even if it’s of my own accord.

My new role offers some exciting opportunities. Foremost, I’ll be working for a great organization with a stellar reputation. I also feel I have a single job that that combines my passion of technology, software development, and software process with that of my desire to learn and teach. I’m excited for what lies ahead, knowing that I must be careful to remember the important real world lessons I’ve learned. I intend to continue writing code, hopefully experimenting with new languages, platforms, and tools. I look forward to working with new organizations, and meeting new people.

Since I’m moving onto what feels like a career change, I’ve also decided to update my web sites (Yes, I love to hack!). First in queue is this blog, which now has a new skin. I’ll also be moving content away from my home page and onto this blog. Eventually, the code I write will reside on Google Code. Probably other presently unforeseen changes too. I’m excited about what lies ahead, and my expectations are high.

For the past two years, I’ve been writing The Agile Developer column at Agile Journal. Most of the articles are small focused pieces that share my experience with a specific agile practice. This month’s theme is sharing agile successes, so I took the opportunity to traverse back through many of my previous articles and discuss how each of these practices fit into a more complete agile development approach. The Agile Roadmap can serve as a launching pad for those teams new to agile, or as a gap filler for struggling teams.

I’m sure there are some omissions and gaps in coverage - some I know of, others I may not. If you feel strongly about a practice or technique not mentioned in the article, please comment.

I wonder if Andy has seen this.

Since it’s inception almost two years ago, I’ve been writing the Agile Developer column for the Agile Journal. Shortly thereafter, I started the Agile Junction blog. While I’ve continued to write the column, I haven’t posted a blog entry in damn near a year. In my new role as Online Editor over at Agile Journal, I’ll be turning my attention toward managing all types of on-line content. Hopefully, that means more blogging, but it definitely means more activity surrounding other forms of on-line content. Thankfully, Liz will still be serving as Editor-In-Chief of the Agile Journal monthly publication. In the next few months, there are going to be some exciting changes taking place at Agile Journal. Be sure to check it out.

Next Page →