I’ve published a summary of the OSGi survey results on the APS blog at Burton Group. Definitely some interesting numbers. The highlights? 80% said they’ll be developing software using OSGi in the next 6 - 12 months, and almost 90% said they would today if their application server supported OSGi. Those are some convincing numbers! The biggest hurdle to OSGi adoption within the enterprise? No surprise here - better enterprise vendor support, integrated toolsets, and more OSGi resources to help understand the benefits and usage patterns.

There are more details to the survey that I’ve yet to explore, and I’ll try to share with everyone what I find after further crunching the numbers

If you haven’t taken the time to fill out the OSGi survey yet, I have to encourage you to do so. The survey will remain live until June 13th. Your feedback and help is greatly appreciated, and I hope to publish the results sometime in June or July

I’ve created a simple on-line survey to gauge interest in OSGi within the enterprise. I appreciate anyone who can spare a few moments to provide their input. I plan to leave the survey open until May 30th, 2008. At some point, I hope to share the results.

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.

(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.

(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.

(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.

(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.

(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.

Quite a few moons ago, I interviewed a gentleman working for a CASE tool vendor. They had just shutdown one of their development shops, and employees had two choices. Find another job, or be relocated. This chap decided to go searching, and our paths crossed. It didn’t take long for me to get way off track with my questions, and eventually I point-blank asked him if they used their own CASE tool on internal development projects. He said “no”, and then nervously suggested that we get the interview back on track. I can’t recall if we ended up hiring the guy, but that interview left an indelible impression and taught an important lesson. If the guy who developed the software doesn’t use it, then you shouldn’t use it. How many open source projects do you think are created where the authors have never used the tool or framework? I’m guessing very few. How many product companies develop products that they don’t use internally? I’m guessing quite a few.

It’s a pretty simple question to ask the next tool vendor trying to sell you their product. If they say yes, then ask them what they like and dislike about the tool. Their honesty is apparent.

The Greater Wisconsin Software Symposium marks the kick-off of the 2008 No Fluff Just Stuff Software Symposiums. The session schedule looks amazing. Traditional sessions on good ole J2EE are still aplenty, but there is also a lot of exciting content surrounding Groovy and Grails, DSLs, Ruby and Rails, Ajax, and agile development that keep things out there on the edge. I’d encourage everyone to attend Sunday’s session on OSGi, which arguably is the most important technology you’ve never heard of - possibly even technology of the decade.

And after a couple months off the tour, you can rest assured that their will be a special energy brought to the conference as it kicks off this year’s tour. Be sure to check it out.

I encountered an incredibly interesting situation recently that clearly illustrates the importance of Continuous Integration. Two separate teams were each working on separate software modules. Eventually, these teams knew they’d need to integrate the two modules into a larger whole. Unfortunately, communication wasn’t that great between the two teams, and while they each had a robust suite of unit tests (they created stubs when testing the integration points between each other), and regularly tested their individual components, they did not ever test them together. Finally, the day came (late in the project, mind you), when the two teams needed to integrate. In fact, integration even went fairly well, with the two modules able to communicate between each other without many problems. Integration testing revealed something alarming, however. A major piece of functionality was missing. Each team thought the other was providing that behavior.

The moral of the story, of course, is that had these separate teams been focused on integrating their two components early and often, this problem would have been discovered much earlier in the development lifecycle. But working in silos is easy and integration is hard. By creating a false sense of progress by avoiding integration until late in the lifecycle, they jeopardized the project.