Kirk's Planet

@kirkk.com blog: JarAnalyzer in Google Code

Thu, 20 Nov 2008 17:01:28 +0000

JarAnalyzer now has it’s own Google Code location. You can browse the source code online, check the source code out, and do all of the other exciting things that you can do with a subversion repository. The source in the google code repository is the same as can be found at the JarAnalyzer homepage (which is also where the binary is still found), except that the Google Code location also contains the JarAnalyzer XSLT.

Eventually, I hope to move the documentation over to the Google repository. Yeah…right! Update the documentation? I don’t think so!

@kirkk.com blog: I’m on Twitter

Thu, 20 Nov 2008 03:06:41 +0000

I’ve jumped on the Twitter bandwagon. Possibly a little slow, but better late than never. I’ve started following a few people, and so far I find it fun and interesting. I intend to post mostly on tech stuff. I’ve also included my tweet feed on the right sidebar of this blog. Or you can subscribe to my tweet feed separately. Or you can start following me now! You decide.

@kirkk.com blog: OSGi interest via MarkMail

Wed, 19 Nov 2008 14:39:07 +0000

An image I swiped from MarkMail showing the increase in OSGi related posts on various mailing lists. No surprise that the most popular lists are Felix Dev and Spring-OSGi. The traffic shows the rise in interest in OSGi the past couple of years. Again, no surprise. It does appear, however, that most of the posts are closely tied to development of OSGi products (like Felix and Spring dm) and not from developers leveraging OSGi within their applications. OSGi hasn’t achieved deep enterprise penetration yet, and won’t until we get support from product vendors along with better tooling.

@kirkk.com blog: The XO Laptop - Give 1, Get 1

Tue, 18 Nov 2008 15:46:17 +0000

The OLPC has instituted their “Give a laptop. Get a laptop.” program again this year. If you’re not familar with the XO laptop, it’s a cool little deviced in a pretty small package. The picture at left shows the XO sitting next to a Dell XPS with a 15″ display (click to enlarge).

The OLPC offered the same deal around the same time last year when I ordered mine, and their was quite a backlog. It took almost six months for them to ship, so if you’re interested in getting your hands on the XO, it might be wise to place the order soon.

You can order your XO through Amazon. For $399, you give a laptop to a child in need, and also get your own laptop.

@kirkk.com blog: OSGi Progress

Thu, 13 Nov 2008 05:49:40 +0000

It’s been a while since I’ve posted. Since I joined Burton Group, I’ve spent most of my time over on the APS Blog. I hope to spend a bit more time here going forward. We’ll see if I can pull it off.

InfoQ recently posted a great snippet on the progress of OSGi in the Enterprise. The article mentions SpringSource, who is clearly paving the trail for OSGi in the Enterprise. While other app server vendors are using OSGi to modularize their platforms, they aren’t exposing the capabilities of OSGi to developers. Eventually, they’ll have to, but for now, they are not. That’s too bad.

If you take a step back and look at what SpringSource has done the last six months, it’s significant. First came Spring Dynamic Modules, which I showed in a previous blog entry. Then SpringSource Application Platform. Then SpringSource dm Server. And now the SpringSource Enterprise Bundle Repository. Of all, it’s the bundle repository that may be most important. While it’s been possible for a while to develop OSGi bundles, the dearth of OSGi tools and third party frameworks packaged as OSGi bundles has been a barrier to entry for enterprise developers. The bundle repository made available by SpringSource has removed that barrier.

While the InfoQ article offered a great synopsis of OSGi in the Enterprise, comparing OSGi to Maven is like comparing a Porsche to a Volkswagon. In other words, there is no comparison. OSGi wins hands down, and while offering the comparison might help explain modularization to those familiar with Maven but not with OSGi, it confuses and dilutes OSGi.

InfoQ does sum it up well, though. "…building dynamic, modular applications is where the industry is headed." That’s spot on. And as OSGi continues to penetrate the market, it means great things for the Java platform.

@kirkk.com blog: OSGi Survey Results

Thu, 19 Jun 2008 14:51:17 +0000

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

@kirkk.com blog: OSGi Survey Deadline Extended

Mon, 02 Jun 2008 19:51:00 +0000

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

@kirkk.com blog: OSGi Survey

Tue, 20 May 2008 05:16:56 +0000

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.

@kirkk.com blog: OSGi & Spring

Tue, 06 May 2008 14:26:54 +0000

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.

The easiest way to show this is by expanding on the HelloWorldSpec sample from my previous post. Reviewing the HelloConsumer and HelloServiceImpl classes reveal that each are rather tightly coupled to the OSGi API. As we’ll soon see, using Spring removes those dependencies, making the Spring edition of HelloConsumer and HelloServiceImpl simple POJOs. Of course, the dependency on OSGi has to live somewhere, and for those familiar with Spring, we know it lives in the Spring configuration files.

The Spring DM configuration files live in a META-INF/Spring directory, which you can see in my Google Code Repository for the HelloWorldSpecSpring project. There are two files, and each are described below:

helloservice.xml - Defines the helloService bean.
helloservice-osgi.xml - Exports the helloService bean as an OSGi service.

It isn’t necessary to separate the configuration into two separate files. However, experienced Spring users typically separate configuration elements to making management and testing easier. In this case, the two configuration files allows me to test the helloService bean outside of the OSGi runtime.

Since Spring is now managing the service within the Felix runtime, I have to install the necessary Spring bundles to Felix. As with the other examples, I’ve done this for you within the HelloWorldSpecSpring project. Of course, when starting Felix, you can always create a new profile by entering a different profile name and install the bundles yourself. The bundles within the SpringLib directory are those I found were required to ensure the Spring DM modules resolvd correctly. If you do choose to create your own profile, it’s likely you’ll have to modify the config.properties file to point to the location of your Felix runtime, which means you’ll have to download Felix to get these bundles since I only include the Felix runtime in the HelloWorldSpecSpring distribution, not the bundles. You won’t have to do this if you use the HelloWorldSpecSpring profile because the bundles have already been installed.

After installing the client.jar and service.jar, I should be able to perform the execute same start, stop, and install sequence described in my earlier post on OSGi & Modularity, and receive the exact same results. Except this time, Spring is managing the dependencies on the OSGi API and my classes remain simple POJOs. Spring’s simple elegance helping yield a higher quality design with fewer dependencies on the OSGi API.

@kirkk.com blog: Software Development Failure

Thu, 01 May 2008 03:46:19 +0000

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.

We fail for many reasons. But mostly, it’s of our own accord. The original CHAOS report, published by The Standish Group in 1994, supports the claim that the primary impediment to successful software delivery surrounds requirements. Since the publication of that report, more evidence has emerged to support its findings:

35 percent of requirements change throughout the software lifecycle (Jones, C. 1997. Applied Software Measurement. McGraw Hill.)
45 percent of delivered features are never used. (Johnson, J. 2002. Keynote speech, XP 2002, Sardinia, Italy.)
82 percent of projects cited incomplete and unstable requirements as the number one reason for failure. (Thomas, M. 2001. “IT Projects Sink or Swim.” British Computer Society Review.)
Large projects, those costing more than $10 million, are successful exactly zero (0) percent of the time. (Johnson, J. 1999. “CHAOS Into Success.” Software magazine.)

Unfortunately, many organizations attempt to rectify this situation by applying traditional software development techniques that emphasize early requirements elicitation and stabilization, followed by the other phases of the SDLC excecuted serially. While a noble goal, it is not possible to stabilize that which is inherently unstable. Experience has also shown me that many process improvement efforts result in little more than a varied manifestation of the same flawed processes that have plagued the software industry for decades. Yes, I put that in bold type for a reason - in many cases, we attempt to solve the problem using solutions that directly contribute to the problem.

Clearly, to improve software delivery, a more nimble and adaptive approach is required. Returning value to IT requires shedding the flawed processes of yesterday, and introducing methods that create greater alignment between IT and business by promising incremental delivery of functional software. Obviously, you see where I’m going with this, but the details will have to wait for another day. Instead, I want to point out some alarming failure statistics.

After five years and $26 million dollars, the University of Wisconsin System discontinued implementation of a system-wide payroll and benefit initiative.

The Department of Workforce Development recently canceled the EnABLES project. Overall, $23.6 million was spent on the project, including approximately $10 million on the phase II appeals system that was never completed.

Wisconsin is attempting to recover $2.1 million after a failed Oracle-based e-mail installation.

In 2005, after spending more than $170 million, the FBI canceled development of it’s Virtual Case File (VCF) without deploying it.

The Software Hall of Shame shows other startling statistics.

I can promise there are many other examples of failure with equally staggering numbers. Why do we fail? In the case of the VCF, failure was the direct result of poorly defined and evolving requirements and overly ambitious schedules.

Obviously, our current approach is not working. In an era where IT services are viewed as an easily obtainable commodity, the onus is on IT to earn back the trust of our business partners. To do so requires a more adaptable and nimble approach to software delivery that results in more innovative use of technology. I’m a firm believer that increased development agility is the fundamental element in software development reform.

@kirkk.com blog: OSGi & Modularity

Thu, 24 Apr 2008 21:36:29 +0000

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.

A classic design statement in the GOF book states that we should separate interface from implementation. Java provides first class support for this heuristic through it’s use of interfaces, and we use it all the time. We know it’s good design. But another important design heuristic less often used states that interfaces should be placed separate from the classes that implement them. By placed, I mean the modules containing those interfaces. The result is subtle, yet has an important impact on design quality. The HelloWorld example serves as a good illustration.

The HelloService interface is the specification implemented by the HelloServiceImpl. It decouples HelloClient from the implementation, and adheres to the GOF heuristic of separating interface from implementation. But bundling the interface in the same component as the implementation compromises design quality, and is the basis for the modularity heuristic above. Why? Because while I can still gain extensibility through new implementations of the interface, I lose flexibility in how I manage the implementations if the interface and implementation are deployed in the same component. For instance, in my previous example where the interface and implementation are deployed in service.jar, I don’t have the ability to dynamically replace the existing implementation with another because I can’t remove the implementation from the OSGi run-time if the interface and implementation are deployed together.

But if I move the interface to a separate bundle, call it spec.jar, while leaving the implementation in service.jar, I do have the ability to swap implementations at run-time when using OSGi. In my Google Code repository exists the HelloWorldSpec project. There are four bundles - client.jar, spec.jar, service.jar, and service2.jar. Still a pretty simple example, but it illustrates the key design heuristic.

In my initial deployment to Felix, I install client.jar, spec.jar, and service.jar. The results are the same as in my previous blog entry. But now, if I deploy and start service2.jar, stop service.jar, and stop client.jar, the OSGi run-time has managed to dynamically adapt to the changing conditions and discovers the service2.jar implementation of HelloWorldService. To experiment for yourself, do something like the folllowing after checking out the project from Google Code:

Build all four projects using ant build.all from the HelloWorldSpec root directory.
Start felix (you may have to modify the script - .bat or .sh - to find the felix.jar).
Use HelloWorldSpec as the profile if you want to use the bundles already installed, or create your own profile if you want to install them yourself.
If you used HelloWorldSpec as the profile, uninstall the service2.jar bundle. If you created your own profile, install spec.jar, service.jar and client.jar.
Stop client.jar and notice the message. Start client.jar back up.
Install and start service2.jar
Stop service.jar.
Stop client.jar again. Notice the message. Cool - an environment adaptable to changing conditions.

As OSGi adoption continues, a new set of design principles are going to emerge surrounding modularity. I show but one example here of the benefit of placing interface in a module separate from implementation. An example of another important design principle enabled by OSGi is a PublishedInterface - public classes in a bundle’s exported packages. Something not supported by the JVM, but enabled by OSGi. In fact, I’ve long been an advocate of the .jar as a first class Java component, and some time ago launched Extensible Java to capture many of these modularity patterns. It’s also why I created JarAnalyzer. It’s time I revisit those ideas.

@kirkk.com blog: Simple OSGi Service

Thu, 17 Apr 2008 20:55:39 +0000

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.

There are numerous OSGi tutorials, blogs, and samples posted around the web. My OSGi resources page lists some of these, and if you know of other good resources not listed, please let me know. When I experiment with a new technology, I like to focus exclusively on the technology itself, without code generators, wizards, or other utilities that do half the work for me. I feel it maximizes the experience. To that end, all of my exercises avoid using tools like Maven or Eclipse. I find Maven confusing and using Eclipse for some of these smaller exercises is overkill. Save for a few necessary tools like Ant and the Felix framework itself, I’ll roll everything by hand. Hopefully, this helps clarify the core essence of OSGi.

The first sample is the canonical HelloWorld example where I create two simple bundles - a client.jar and service.jar. Again, in OSGi parlance, a bundle is a .jar file. You can find the working code in My Google Code repository (the HelloWorld project), complete with the Ant build script, the bundle cache, and a .bat or .sh script to start Felix depending on your OS. The only two prerequisites for these samples is Felix (I used version 1.0.0) and Ant, which you’ll have to download separately. Let’s walk through the creation of these two simple bundles.

First, let’s look at HelloConsumer in client.jar. HelloConsumer uses the HelloService to get the hello and goodbye messages when the client.jar bundle is started and stopped, respectively. HelloConsumer implements OSGi’s BundleActivator, meaning Felix will invoke the start method when the bundle is started, and the stop method when the bundle is stopped. As seen on line 26, HelloConsumer obtains a reference to the HelloService using the OSGi ServiceTracker class.

The HelloService and HelloServiceImpl form the OSGi service. HelloService is a simple Java interface that defines the API, while HelloServiceImpl implements the BundleActivator and is the class invoked when the server bundle is started and stopped. As seen on line 18, HelloServiceImpl registers itself as an OSGi service. Without registration, HelloConsumer would not be able to use HelloService as an OSGi service.

There’s a bit more magic here that makes this all work. A wonderful aspect of OSGi is that dependencies must be managed explicitly, with each bundle’s manifest declaring the packages the bundle imports and exports. Bundle manifests specify other key pieces of information, too. Notably, it tells the OSGi environment of the BundleActivator to invoke on start and stop. If a bundle imports a package, then another bundle within that OSGi run-time must export that same package. The client bundle manifest imports the package containing HelloService while the service bundle manifest exports that same package. Were these imports and exports not explicitly declared, we’d receive OSGi run-time errors. In our example above, HelloServiceImpl registers itself as an OSGi service allowing clients to obtain a reference to HelloService using the OSGi ServiceTracker.

The client and service OSGi bundles can be deployed to any OSGi run-time. I’ve used Felix for this example, but could have used Equinox just as easily. To run these examples, you can checkout the code from the Google Code repository. Since I include the bundle cache in the repository, you should be able to start felix and experiment with OSGi. You’ll likely have to modify the start script (OS-based) to ensure Felix is in your classpath. Upon starting Felix, you’ll be asked to enter a profile name. To use the bundle cache included with the example, simply use HelloWorld as your profile.

If you’re feeling a bit more adventurous, you can make some changes to the HelloServiceImpl message and rebuild the project by invoking the Ant build script. Once compiled, move back into the Felix shell and update the service bundle using the Felix update command. For a listing of all Felix commands, simply type ‘help’.

If you want to deploy the bundles to your own Felix cache, restart Felix and enter a different profile name. Any name will do, and Felix will create a new bundle cache for you. Here are some more suggested steps to build, install, and continue experimenting with the bundles and OSGi:

Build service by executing ant within service directory
Build client by executing ant within client directory
Run startfelix.bat or startfelix.sh depending on your OS
install the bundles from the felix shell
- install file:service/bin/service.jar
- install file:client/bin/client.jar
- ps
- start {service-bundle-id}
- start {client-bundle-id}
Experiment by starting and stopping client and service to get a feel for OSGi.
Now change the service message printed in HelloServiceImpl.java and compile. Then do the following while client is running.
- stop {service-bundle-id}
- update {service-bundle-id}
- start {service-bundle-id}
- stop {client-bundle-id}

When stopping the client bundle, you should see a different goodbye message than what you saw in step 4.

OSGi offers a very dynamic and adaptable run-time environment. Even when not using OSGi services, reuse across bundles can occur so long as the package dependencies are explicitly managed in the bundle manifests. The benefit with OSGi services is that the OSGi run-time manages the service lifecycle, however. Many of the presentations I give on architecture & design talk about the importance of managing .jar relationships, and I’ve long felt that the .jar file is a great candidate as a first class component on the Java platform. In the next post, I’ll explore the simple benefits of an incredibly important heuristic that states we should “separate interface from implementation.” You can get a head start by taking a look at the HelloWorldSpec project on My Google Code repository.

@kirkk.com blog: The H-1B Fraud

Thu, 03 Apr 2008 13:29:36 +0000

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.

@kirkk.com blog: IT Labor Shortage Myth

Thu, 27 Mar 2008 04:38:22 +0000

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…)

@kirkk.com blog: New Job New Skin

Tue, 25 Mar 2008 04:31:10 +0000

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.

@kirkk.com blog: The Agile Roadmap

Wed, 12 Mar 2008 15:40:08 +0000

For the past two years, I’ve been writing The Agile Developer column at Agile Journa l. 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.

@kirkk.com blog: Code Quality’s Singular Metric

Thu, 14 Feb 2008 14:24:31 +0000

I wonder if Andy has seen this.

@kirkk.com blog: Agile Journal

Wed, 30 Jan 2008 22:26:57 +0000

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.

@kirkk.com blog: Eat your own Dogfood

Fri, 18 Jan 2008 17:58:19 +0000

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.

@kirkk.com blog: Fluff Season Kick-Off

Fri, 11 Jan 2008 19:46:06 +0000

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.

@kirkk.com blog: Importance of Continuous Integration

Fri, 28 Dec 2007 18:42:20 +0000

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.

@kirkk.com blog: SpamBots Getting Through

Thu, 06 Dec 2007 00:36:45 +0000

I use WordPress as my blogging system, and a while back, I installed the Challenge Captcha. But recently the SpamBots broke it and have been able to find the correct answer to the math questions. As a result, they’ve been leaving their nasty comments. So, I’ve reconfigured the Challenge to ask the question in a more English style. I guess it’s pretty easy for the SpamBots to evaluate “3 x 4 + 2″. But now we’ll see how easy it is for them to evaluate “What is the sum of 2 and 4″.

I really don’t know who has the time or energy to waste on such things. And I don’t know what they are trying to accomplish other than being a nuisance.

@kirkk.com blog: Agile 2008

Wed, 05 Dec 2007 05:30:47 +0000

Agile 2008, being held in Toronto August 4 to 8, seems like a long ways away. However, the submission system just went live this week. I’m excited because I have the opportunity to help organize the Developer Jam stage. There are a few changes surrounding the conference for 2008, starting with the submission system, which is wide open to the public. Any session proposed can be reviewed by any registered user, so hopefully we’ll build some great sessions with the level of community involvement we hope to achieve. Because the conference has been a sell-out the past few years, we’ve also secured a venue in Toronto that can host up to 1600+ individuals.

But what’s most exciting for me is the return of agile in the trenches…getting down and dirty with the developer again. My main issue with last years conference was that it seemed to have forgotten about the developer. There was so much “agile in the enterprise this”, and “application lifecycle management that”. So I’m very excited to help build a track (we’re calling them stages) that focuses exclusively on the developer. I know we can all still stand to learn more about unit testing, continuous integration, refactoring, and more. Please, take a look at the Developer Jam, submit a proposal or two, and provide some constructive feedback. We’ve assembled a great review committee consisting of some outstanding professional developers (listed at the bottom of the Developer Jam page). Let us know what you think would be cool to incorporate into the Developer Jam stage at Agile 2008.

@kirkk.com blog: Crap4J - Alarming EULA

Fri, 02 Nov 2007 03:19:09 +0000

Updated (11/02/07) : Please note the responses from Alberto and Bob attached to this post. They’ve offered some assurance that Crap4J does not transmit any code to their servers, and that the licensing snafu was due to a simple oversight. They also resolve to correct the licensing agreements. Thank you, Alberto and Bob! : End Update

I went to install the Crap4J Eclipse plug-in. As part of this plug-in, there are four separate features, and I happened to actually read the license agreement for each of them. In a nutshell, for three of the features (Agitair JUnit Runner, Agitair JUnit4 Suport, and Public API for Generated Tests), the license agreement states that the software is experimental and primarily for academic, research, and open source use. But that’s not the alarming part. It also says that it transmits your code over the open internet to be analyzed on non-secure Agitair computers shared by multiple users. Here’s the exact text:

THIS SOFTWARE IS INTENDED PRIMARILY FOR ACADEMIC, RESEARCH, AND OPEN SOURCE
USE. WHILE COMMERCIAL USE IS ALLOWED, PLEASE BE AWARE THAT YOUR CODE
IS TRANSMITTED OVER THE OPEN INTERNET AND ANALYZED ON NON-SECURE
COMPUTERS SHARED BY MULTIPLE USERS.

I don’t like that much, and it seems a bit sneaky to hide that rather important note in a license agreement that I doubt many folks read. There should be a more noticeable disclaimer somewhere. Also, I found no such notice in the Ant Task distribution (in fact, couldn’t find a license agreement included at all). But that’s not saying the Ant Task does or does not transmit your code.
I don’t know the internal behavior of Crap4J. Maybe it doesn’t send your code anywhere. But the license agreement indicates that Crap4J does, or at the very least, that they have the right to do so. Maybe, giving them the benefit of the doubt, they didn’t fully review the license agreement, and aren’t aware of what it says. Either way, the fact that this important note is buried within a license agreement without any other public disclaimer is very alarming and deceiving.

@kirkk.com blog: Big Software

Wed, 31 Oct 2007 02:05:40 +0000

I saw the news item on InfoQ regarding MicroSoft Oslo. There was quite a bit marketing mumbo jumbo surrounding Oslo, SOA, BPM, composite applications and MDD, and not a lot of it resonated with me all that much. However, one quote did stand out.

We want to send the model to the server not the printer.

This got me thinking about Big Software in general, even if it isn’t about SOA, BPM, and a lot of other standard industry buzzwords. Developing large enterprise systems comes with a lot of baggage that smaller development efforts don’t have, and a larger codebase is part of it. There are a lot of techniques that teams apply in attempts to architect, maintain and downright understand large software systems. In fact, the problem understanding Big Software is one of the compelling forces that led me to create JarAnalyzer. Since no one person can understand all detailed aspects of a large system, give people high level visual insight into the component relationships and let them drill down from that point. Unfortunately, there is no “drill down” capability in JarAnalyzer - you only get the .jar relationships and a few metrics. But combine it with tools like JDepend, and UMLGraph and you can get a few different views. Either way, there are quite a few different techniques that can be used when it comes to dealing with large codebases. But it seems like most approaches have serious holes.

UML Modeling. UML Modeling is typically associated with Big Design Up-Front. While I don’t agree with detailed design up-front, establishing some idea of how you want to approach design is a good idea. I don’t like designing individual use cases, but do find value in modeling application frameworks, for example. There are a few advantages in doing this. The entire development team understands the general direction. Nothing is ever set in stone, so if something changes, it also serves as a vehicle for communication. Creating a design model also offers you the opportunity to structure the model in a way that best fits your team and how developers will want to interact with and navigate the model. Unfortunately, the greatest problem with modeling is that keeping your model in sync with the source code is impossible, and most reverse engineering solutions suck. So, any modeling done needs to be at a sufficiently high enough level of abstraction such that detailed change doesn’t impact it, or the models must be short-lived, serve their immediate purpose, and then get filed in the trash bin. Generally, I like to do a bit of modeling early, followed by TDD to drive out the details of my designs.
Post-Construction Software Visualization. Quite a few static structural analysis tools generate some form of diagram. JarAnalyzer, JDepend, and UMLGraph are examples. Some exist for the .Net platform, too. The obvious advantage is that you get an up-to-date accurate snapshot of your software system. That’s valuable. Unfortunately, the diagrams aren’t always laid out to give you the view into the system that you’d like. Tools like GraphViz do a great job laying out the diagram, but a diagram is just a single view into a system, and possibly not the view I’m looking for. They aren’t complete models, and since the output of these tools are usually images, they typically aren’t navigable. Static structure analysis is only half the battle…maybe less. Understanding class, package, and component relationships is important, but with frameworks like Spring, it’s virtually impossible to get a feel for run-time structure and behavior. Two packages might have no structural dependency between the two, but the placement of abstractions could result in a run-time relationship. I know of no tool that does a good job analyzing the run-time structure.
Metrics. Many static analysis tools generate metrics and other type of feedback that provide insight into code quality. Most of these don’t necessarily help you understand a system better, but they can help you create a system that is more easily understandable. I like metrics to help guide refactoring, because the design as it’s manifest in code is not always the design as it’s envisioned in the mind of the developer. Metrics offer objective advice on the quality of your application that should be used subjectively. A great resource for analysis tools for Java/JEE development is java-source.net.
DSM matrices. I haven’t done much work with Dependency (aka. Design) Structure Matrices, but I intend to explore. I’ve talked to a few co-workers who have found them useful.
MDD. Model-Driven-Development has been thrown around the industry for a while. If anyone has actually had any great deal of success developing Big Software using MDD, I’d love to hear about it. I’m very skeptical.

If I had the perfect solution, it would be real-time visualization of the source, be it static or dynamic, with the ability to create different views of the system. I’d be able to start high-level, with either .jar or package relationships. Then drill down into the .jar and packages to view details. But I’d easily be able to filter out information that I didn’t want to see. For instance, I might want to see the class diagram for a particular package, but in a different diagram I might want to see the class diagram for only those classes that span packages while suppressing classes that have relationships only to other classes in a package. I’d like to capture the behavior of a running system as a sequence diagram, and I’d like to double-click on any class or object and view the source. It’d be perfect if all this would integrate with my Spring configuration files, so I can build that into a view of the system, too. Of course, I want my metrics. I’d like an API available so that I could write unit tests that validate my design. And most important, if I have all of this coolness, I want the ability to filter out the noise. Essentially, I’d like to combine the navigability and view aspects of modelling with the accuracy of post-construction visualization. I need to make sure my models are accurate, but I also want different views into the system depending on what I’m looking for. And I’d like this wonderful tool available as an Eclipse plug-in, standalone IDE, and Ant task. I want all of this, and I want it to perform well, too. Vendors might claim their tool does this for me, but I know it doesn’t.

What’s your wishlist?

@kirkk.com blog: Enterprise OSGi

Wed, 17 Oct 2007 03:13:10 +0000

For years, OSGi technology has flourished in the embedded systems and networked devices market. Till now, it’s remained a relatively obscure technology for the enterprise developer. Now, in part thanks to Eclipse, OSGi is emerging as a viable and valuable technology in the enterprise.

In 2003, the Eclipse team began looking for ways to make Eclipse a more dynamic Rich Client Platform and increase the platform’s modularity. Eventually, the team settled on the OSGi framework as the run-time component model, codenamed the project Equinox, and in June of 2004 released Eclipse 3.0. This newest version of Eclipse sported a runtime model based on OSGi. OSGi was no longer a technology isolated to use in embedded software and networked devices, but had now become the foundation upon which all Eclipse plug-ins would be developed, and the platform upon which thousands of software developers would use the Eclipse IDE to develop software. Eclipse adoption of OSGi marked a significant milestone for the OSGi Alliance, as adoption by a major product and brand such as Eclipse thrust it into the spotlight for many commercial software companies. Today, several major vendors build on OSGi, and almost all application servers used within the enterprise currently support, or plan to support, OSGi. While OSGi has not yet made significant in-roads to the enterprise, server-side support for OSGi is going to facilitate adoption of OSGi in the enterprise. And this is where it gets interesting for the enterprise Java software developer.

OSGi is a dynamic module system for Java. There is quite a bit of literature discussing OSGi at the OSGi Alliance, specifically the OSGi Technology page. Instead of rehashing what’s already been said, I want to focus on how OSGi is going to influence positive change for the enterprise developer creating server-side software applications.

Modular Development - The OSGi framework defines a unit of modularization called a bundle. A bundle is nothing more, and nothing less, than a Java .jar file. A .jar file is a valid OSGi bundle if it contains resources that provide functionality, and a Manifest file containing metadata about the bundle. The resources can be Java classes, html, images, Servlets, and even JSP. The metadata is defined using required and optional key/values pairs. Since all developers are familiar with .jar files, creating a valid OSGi bundle is relatively straightforward. OSGi changes the deployment model for enterprise applications. Traditional thinking is centered around web application development, and teams devote valuable resources to identifying functionality contained within webapps, and inter-webapp communication. With OSGi, you won’t develop traditional web applications. Instead, you’ll develop bundles that are assembled into an application, so your development philosophy turns from application-centric to component-centric. While we’ve been attempting to design modular software for a very long time, OSGi enforces the design of modular software through these bundles and managed dependencies.

Managed Dependencies - OSGi accepts reality that the .jar file is the predominant method of reuse and deployment with Java. OSGi treats a .jar as a first class component. The Manifest within an OSGi bundle defines export packages that other bundles can use, as well as import packages used by the bundle. Think of this as public and private access to the packages within a .jar file. With OSGi, you can now truly establish a component’s published interface simply through how classes are allocated to packages, and the packages made visible through export by a bundle. OSGi offers local transparency for it’s bundles, because you don’t need to include .jar files on the run-time classpath. Instead, exported packages within an OSGi bundle can be used by other bundles running on the OSGi platform. Optionally, some OSGi implementations may provide a Security layer that allows access to a bundle if permission has been granted.

Component Platform - OSGi is a service platform because it reduces coupling between bundles. Yet viewing OSGi as only a service platform tends to lump it in with all other service (as in SOA) solutions. OSGi is also a true component platform that hits a sweet spot not presently accommodated for in enterprise Java development or SOA. OSGi is not a distributed service technology. Instead, OSGi bundles are deployed and communicate within a single JVM, making inter-bundle communication in-process and lightweight. OSGi bundles are true software components. The OSGi platform contains a framework specification, making it similar to any other specification you’ve worked with in Java, like the Servlet API, JDBC, etc. There will be numerous implementations of the OSGi specification, but your code should only ever refer to the OSGi package structure (org.osgi.*). Additionally, when you compile, you’ll want to compile against the specification, not the specific implementation you choose to use.

Versioned Bundles - When exporting and importing packages from other bundles, you can specify a version number. Because bundles can be versioned, you can deploy multiple versions of the same bundle on the OSGi platform without experiencing fatal errors, such as a ClassCastException commonly experienced when the same class definition is deployed multipled times within the same JVM.

Dynamic (Re)Deployment - OSGi allows you to deploy bundles individually, without performing a restart. When functionality within a bundle changes, you simply redeploy that bundle to the appropriate OSGi platform, and clients of that bundle automagically discover it through the packages it exports and it’s version. No need to redeploy entire applications. This offers tremendous flexibility if you separate implementation from specification in your application bundles, by allowing you to completely swap implementation without any interruption to other deployed bundles.

Environmental Control - Because OSGi is a managed container environment, you have the ability to install, start, stop, update, and uninstall individual bundles.

Let’s take a moment, digest exactly what OSGi entails, and examine what it means for the enterprise developer in the trenches. No longer need we emphasize development and deployment of individual web applications and portals. Instead, we develop enterprise software systems as a composition of software components that can be assembled dynamically to form a complete system. The challenge of inter-application communication is a non-issue, since individual components can expose resources that serve content to the user, and consume behavior exposed by other components. No longer need we redeploy an entire suite of enterprise software systems due to a behavioral change in a single .jar file. Instead, simply update the .jar on the OSGi platform.

Extending the software system to support new processes is as simple as deploying or redeploying only the necessary components, without any interruption to critical processes. An SOA built on web services is also assembled from the same software components by simply building a service protocol layer on top of the appropriate components. It’s possible to assemble a rich client application from the same software components. Additionally, it’s possible to allow separate components within an OSGi container to utilize the behavior of different versions of the same component.

Because component dependencies are explicitly stated, the component structure of the application is well understood. At the very least, this minimzes the risk of change as the ramification of change can be more accurately assessed. Since OSGi bundle collaboration is in-process, granularity of components can be established that allow teams to maximize component reuse without incurring performance degradation due to excessive inter-component collaboration. Overall, OSGi has eliminated many architectural challenges with enterprise software development, and has established more refined techniques for deploying and managing enterprise software.

When you add it all up, OSGi fills an important technology gap between SOA and object-oriented design on the Java platform. For some time, we’ve been able to build flexible and extensible class structures in Java. With technologies such as EJB (primarily Sessions Beans and Message Beans) and web services, we’ve had a service deployment model. But we’ve lacked a robust component model. Today, there are several server-side open source implementations of the OSGi platform, including Server-Side Equinox and Apache Felix, as well as several commercial implementations. The current development release of Spring-OSGi supports building Spring applications that run in an OSGi environment. In typical Spring fashion, Spring managed OSGi bundles eliminate dependencies to OSGi. The Java Open Application Server v. 5 (JOnAS) is designed with an OSGi based architecture. Even Sun is noticing as is evident through the ongoing saga of JSR-291 and JSR-277. And interest in OSGi doesn’t stop there, as a quick Google search reveals.

OSGi is a key technology filling an important void in enterprise software development. While OSGi adoption within the enterprise may be a year or three away, as the platform continues to gain momentum it’s going to offer significant benefits to enterprise software development teams.

@kirkk.com blog: Rotting Design

Mon, 08 Oct 2007 18:20:29 +0000

Design Rot

We’ve all experienced that sinking feeling when maintaining a piece of crappy software. Has my change broken the system in some unintended way? What is the ramification of my change on other parts of the system? If you’re lucky, and the system has a robust suite of unit tests, they can offer some support in proving your work. In practice, however, few systems have thorough automated test coverage. Mostly we’re alone, left to verify our changes as best as possible. We might privately criticize the original developers for creating such garbage. It certainly lends a plausble excuse in explaining why the maintenance effort is so costly or time-consuming. Or it might serve as the basis upon which we recommend a re-write. But mostly, we should wonder how it happened.

For sure, most software doesn’t start out this way. Most software starts out clean, with a clear design strategy. But as the system grows over time, strange things begin to happen. Business rules change. Deadline pressures mount. Test coverage slips. Refactoring is a forgotten luxury. And the inherent flaws present in every initial design begin to surface. Reality has proven that few enterprise development teams have the time or resources to fix a broken design. More often, we are left to work within the constraints of the original design. As change continues, our compromises exacerbate the problem. The consequence of rotting design is seen throughout the enterprise on a daily basis. Most apparent is the affect on software maintenance. But rotting design leads to buggy software and performance degradation, as well. Over time, at least a portion of every enterprise software system experiences the problem of rotting design. A quote from Brook’s sums it well:

All repairs tend to destroy the structure, to increase the entropy and disorder of the system. Less and less effort is spent on fixing the original design flaws; more and more is spent on fixing flaws introduced by earlier fixes. As time passes, the system becomes less and less well-ordered. Sooner or later the fixing ceases to gain any ground. Each forward step is matched by a backward one. Although in principle usable forever, the system has worn out as a base for progress.

The most obvious question is, “How do we prevent rotting design?” Unfortunately, rotting design is not preventable, only reducable. As design is an essential complexity, it cannot be eliminated, only minimized. Of the past ten years, the design patterns movement has provided insight to the qualities of good design, helping minimize the essential complexity. Dissecting design patterns reveals many important design principles that contribute to more resilient software design. Favor Object composition over class inheritance, and program to an interface, not an implementation, are two examples. Of the 23 patterns in the GOF book, all adhere to these fundamental statements. Alone however, today’s design patterns are not enough to help reduce rotting design.

Reducing Rot

Most patterns emphasize class design, and present techniques that can be used in specific contexts to minimize dependencies between classes. Teasing apart the underlying goal of most respected patterns shows us that each aim to manage the dependencies between classes through abstract coupling. Conceptually, classes with the fewest dependencies are highly reusable, extensible, and testable. The greatest influence in reducing design rot is minimizing unnecessary dependencies. Yet enterprise development involves creating many more entities beyond only classes. Teams must define the package structure in which those classes live, and the component structure in which they are deployed. Increasing the survivability of your design involves managing dependencies between all software entities - classes, packages, and components.

But if minimal dependencies were the only traits of great design, developers would lean towards creating very heavy, self-contained software entities with a rich API. While these entities might have minimal dependencies on external resources, extreme attempts to minimize dependencies results in excessive redundancy across entities with each providing its own built-in implementation of common behavior. Ironically, avoiding redundant implementations, thereby maximizing reuse, requires that we delegate to external entities, increasing dependencies. Attempts to maximize reuse results in excessive dependencies and attempts to minimize dependencies results in excessive redundancy. Neither is ideal, and a gentle balance must be sought when defining the behavior, or granularity, of all software entities - classes, packages, and components.

Software design is a constant quandary. Any single element key to crafting great designs, if taken to its individual extreme, results in directly the opposite - a brittle design. The essential complexity surrounding design is different for every software development effort, for similar domains across organizations, and for different phases throughout the life of a software product. The ideal design for a software system is always the product of it’s current set of behavioral specifications. As behavior changes, so too must the granularity of the software entities and the dependencies between them. The most successful designs are not characterized by their initial brilliance, but instead through their ability to withstand the test of time. As the complexity of software design is an essential complexity surrounding software development, our hopes lie with technologies and principles that help increase the ability of your design to survive over time.

Future of Design

I’m hopeful that all software developers have experienced the pleasure of a design that, through the course of time, has withstood the test of time. Unfortunately, many enterprise development teams have too few of these experiences. Likewise, few enterprise development teams devote adequate effort to package and component design, serving as a significant contributor to our inability to realize the promised benefits of object-oriented development. It’s unreasonable to believe that even the most flexible class structure can survive should the higher level software entities containing those classes not exhibit similarily flexible qualities. The problems are rampant. Increased dependencies between packages and components inhibit reusability, hinder maintenance, prevent extensibility, restrict testability, and limit a developer’s ability to understand the ramification of change.

SOA and Web Services promise to remedy our failures with object-oriented development. While Services may offer tangible business value, within each awaits a rotting design. There exists a world between class design and web services that deserves more exploration, and as an industry, we are beginning to notice. Currently, the Java Community Process (JCP) is developing three separate JSRs that emphasize greater modularity for the Java platform. JSR-277 is creating a static module system for Java, part of which aims to establish a mechanism for expressing and enforcing the dependency between .jar files. JSR-291 references OSGi, a proven component technology providing a dynamic module system for the Java platform. JSR-294 focuses on VM and language support for modularity. For some time, Maven has supported flexible ways to select specific versions of a component, as well as support for managing transitive dependencies. JDepend and JarAnalyzer are two utilities that provide feedback on package and component design, respectively. All aim to help manage the complexity, from design through deployment, of enterprise software development. With each, new practices, heuristics, and patterns will emerge that increase the ability of a design to grow and adapt.

@kirkk.com blog: Java Components & OSGi

Wed, 03 Oct 2007 04:31:39 +0000

Because of it’s emerging significance and my increased interest, I’ll be posting a number of entries related to OSGi. I’ll share some ideas on how OSGi stands to transform enterprise Java software development and application delivery, present some samples that illustrate these ideas, and offer a few opinions regarding the JCP and the various JSR’s that intend to accomplish similar ideals. I’m hopeful that my unbiased opinion will help developers more fully understand the value that OSGi brings to the enterprise. To help you quickly find all OSGi related entries on this site, I’ve created a separate blog category under which I’ll file these posts. I’ve also added a separate page that links to a number of other useful OSGi specific articles, websites, and blogs. If you are aware of an on-line resource related to OSGi, or know of one not on the current list, let me know and I’ll add it.

For quite some time, I’ve felt that the lack of a component technology has left a gaping hole on the Java platform. In fact, this is what led me to begin development on JarAnalyzer back in 2001 in the hope that I could help developers understand the component modularity of their existing applications. It’s also what led me to found Extensible Java in the hope that I could offer some design guidelines surrounding component modularity when developing large enterprise software systems in Java. The idea of a component technology that brings greater modularity to the Java platform is very exciting. This is my first OSGi-related post, so let’s start at the beginning. Why?

The distiction between software architecture and design is subtle, and countless trees have been sacrificed attempting to differentiate between the two. Booch sums it well, pointing out that it’s the cost of change separating the two.

All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.

Cost of change can be measured in many different ways, and is contextual. Financial cost, technological risk, and derived business value are examples of what might factor into that cost. However you slice it and dice it, the business value of design is to craft a software design that minimizes the cost of change by maximizing adaptability to change.

The ability of software to adapt, however, is not constant. As unexpected shifts in technology and business occur, the original design may not accommodate current needs. Should this occur in an architecturally significant area of the system, the cost of applying the correct change may exceed the immediate business value. As this happens throughout the life of a software system, software design degrades to the point where most change is no longer cost effective, and the temptation to hack a compromised solution is great. As this begins, and continues to occur, the software is beginning to rot.

Fowler discusses Design Stamina Health in making the compelling case that software design is a worthwhile activity. I doubt many of us disagree with his conclusion, assuming that the resulting design realizes the intended goal - that it can evolve. While good software designs are able to evolve based on the known factors today, the unforeseen factors of tomorrow reap havoc on design. I doubt we can ever entirely defeat these forces, but many techniques have been discovered that allow us to craft more adaptable software designs. Object-oriented development, design patterns, software code quality metrics, design quality principles, emergent design techniques such as Test-Driven Development, and Service Oriented Architecture all represent a positive step. Yet for large enterprise software systems, there is still a key ingredient missing in delaying design rot. On the horizon looms a disruptive technology, codename OSGi, that stands to redefine how we think about designing enterprise software on the Java platform.

@kirkk.com blog: Getting Blasted

Thu, 27 Sep 2007 03:41:11 +0000

I got blasted for the following quote in a recent eWeek article:

“If you’re in a large environment that is bureaucratic, filled with politics and has a [software development] process like the waterfall flavor of RUP [Rational Unified Process] what do you do?” Knoernschild asked. “It’s been my experience that the number one thing you can do is continuous integration. That can spawn so many business benefits.”

The blaster suggested that I have no idea what I’m talking about because there is no “waterfall flavor of RUP”. What I believe the blaster missed is the tongue in my cheek when I made the comment.

As is often the case, the quote didn’t capture the context of the statement. Many teams, when transitioning to an iterative process, commit a number of mistakes. One of the more common mistakes is to establish iterations centered around the traditional lifecycle phases. When I made the comment, I also pointed out that the “waterfall flavor of RUP” typically consists of the first iteration being the requirements iteration, followed by the design iteration, followed by the construction iteration, followed by the testing iteration, etc.

@kirkk.com blog: Class, Component, Service

Wed, 12 Sep 2007 04:23:22 +0000

A class defines the variables and methods available to it’s specific instances. A class serves as the blueprint for an object. An object is an instance of a class with state. In Java, a class is a .class file

A component is a unit of deployment. A component contains classes. Components are invoked in-process (locally). Components are not instantiable. Components are stateless. Component interactions are synchronous. In Java, a component is a .jar file.

A service is a software system. Services are distributed, may execute in different processing environments, communicate over a network, and are invoked remotely. A service is not instantiable. Services are stateless. Service interactions are synchronous or asynchronous. A service contains components. In Java, a service is an .ear file with the appropriate deployment descriptor.

Agree or Disagree? I’m interested in your thoughts on this subject…

@kirkk.com blog: New JarAnalyzer XSL

Fri, 07 Sep 2007 12:55:10 +0000

JarAnalyzer has always had the ability to create a dot-compliant output file that could be used with GraphViz to generate a component diagram. In the past, this had always been done using the DOTSummary class. Unfortunately, this meant that if you wanted to generate output files in both xml and dot, you had to run JarAnalyzer twice. Now, thanks to a stylesheet that I graciously stole from JDepend and modified to work with JarAnalyzer, there’s a new way to generate a dot-compliant output file that is much nicer than what you’ll get when using DOTSummary. Plus, you only have to run JarAnalyzer once, then apply two stylesheets to the xml file generated to get both the html report and component diagram.

In addition to being a bit more efficient, it’s also cleaner. The old component diagram is shown at left on top, while the new component diagram using the stylesheet is shown at bottom left. The stylesheet avoids the confusion where DOTSummary changed the name of the .jar file and stripped off the .jar extension. As seen on the diagrams, a .jar file named bill.jar now actually appears as bill.jar on the component diagram, not bill.

The new stylesheet isn’t part of the JarAnalyzer distribution…yet, but you can download the stylesheet. To run JarAnalyzer as part of your Ant build script and get both the html and component diagram output, drop the stylesheet in the directory containing JarAnalyzer (the same directory with jaranalyzer.xsl), and modify your build script similar to the following (you need GraphViz installed to run dot):

<target name="dotanalyzerapp.new" depends="bundle">
   <taskdef name="jaranalyzer"
                  classname="com.kirkk.analyzer.textui.JarAnalyzerTask">
       <classpath>
           <pathelement path="${buildlib}/jaranalyzer-1.2.jar"/>
           <pathelement path="${buildlib}/lib/bcel-5.2.jar"/>
           <pathelement path="${buildlib}/lib/jakarta-regexp-1.3.jar"/>
           <pathelement path="${buildlib}/lib"/>
       </classpath>

   </taskdef>

   <jaranalyzer srcdir="${buildstats}" destfile="${buildstats}/appdependencies.xml"
                      summaryclass="com.kirkk.analyzer.textui.XMLUISummary"/>

   <style in="${buildstats}/appdependencies.xml"
                    out="${buildstats}/appdependencies.html"
                    style="${buildlib}/jaranalyzer.xsl">
   </style>

   <style in="${buildstats}/appdependencies.xml"
                    out="${buildstats}/appdependencies.grph"
                    style="${buildlib}/jaranalyzer2dot.xsl">
   </style>

   <exec executable="dot" ><arg line="-Tpng -Nshape=box -Nfontsize=30 -Nwidth=1.5
              -Nheight=1.25<br></arg> ./buildstats/appdependencies.grph
              -o ./buildstats/appdependencies.png">
   </exec>

 </target>

@kirkk.com blog: Palm Treo 700p

Wed, 29 Aug 2007 15:02:25 +0000

About a month ago, I went out and purchased a Palm Treo 700p (yes, I purchased it even after the release of the iPhone). Prior to the Treo, I had a regular ole’ LG (model unknown) that I used as a phone, and a BlackBerry (model 7250) that I used for my data needs (browsing and e-mail). I decided to use the Treo to serve both my phone and data needs. So far, there’s been good, bad, and ugly.

First, the good.

The phone is decent, neither better nor worse than my LG through U.S. Cellular. Reception with Verizon is about the same, and I still experience the same volume of dropped calls and missed calls due to the phone failing to ring. The touchscreen keypad works well, with fairly large numbers that help prevent mistyping the numbers. The Treo is a bit large for a phone, and it’s shape doesn’t feel entirely natural pressed against the side of my head. The detailed call log is nice.
The Blazer browser accesses most of the sites I need when in a pinch. For a more pleasurable browsing experience, I can always tether the phone to my Mac anywhere I get reception. The lack of built-in WiFi isn’t a huge concern because of the ability to tether the 700p to my Mac. However, after seeing Safari on the iPhone, I was a bit jealous.
Initially, I used VersaMail as my default mail client, but quickly abandoned that experiement because of a few minor annoyances related to the user interface and my inability to configure VersaMail in a way that wouldn’t download duplicate messages without deleting them from the server. I installed a Java VM and went with the GMail client instead. Since I send e-mail using GMail (web-based), my Mac, and the Treo, the GMail client for my Treo is nice as I minimize the number of Outboxes I have that require searching when I want to find a sent mail item.
I use iCal on my Mac which syncs well with my Google Calendar. While it’s pretty easy to sync between iCal and the Palm’s Calendar using iSync, since I use Google Calendar as my system of record, I preferred to sync with Google Calendar directly. GooSync allows me to do an over-the-air two-day sync with my Google Calendar. That’s a pretty nice feature, but I did have one instance where a future appointment wouldn’t sync correctly. I couldn’t repeat it and it hasn’t happened again, so right now, I’m treating it as an anamoly. It’s nice knowing that I can enter an appointment on my Treo or in Google Calendar and the two-way sync takes care of the rest.
Messaging on the Treo is much nicer than my old LG as the display shows the entire history of a conversation.
Tethering my phone to my Mac via a Bluetooth connections gives me web access anywhere I get cell reception. This is similar to how the Verizon Wireless Card works. Connection speed is suitable for most of my browsing needs (around 200k), but the connection seems to get lost if I remain idlefor longer than 30 seconds to a minute. While somewhat of a pain, it’s quick enough to reconnect that it’s tolerable.
I really like the 1.2 MegaPixel camera as the quality is obviously much better than the VGA camera on my old phone. I’m constantly using it to snap pictures of the kids. The camcorder video is rather choppy, but capturing a precious moment in the absence of my Sony camcorder is better than not.
Palm has a pretty healthy development community and subsequently, there’s a plethora of software available for the Treo 700p. Google maps is a definite sweet spot that offers turn by turn directions. BackupBuddyVFS offers a way to backup the entire contents of the device to my SD card.
Mac integration is fairly solid with the 700p. Using iSync, I can easily sync with Contacts and iCal, though syncing for me is primarily for backup purposes over anything else. I use GooSync to sync with Google Calendar and have seutp iCal to subscribe to my Google Calendar, so there isn’t any need to sync my Treo Calendar with iCal.

Now, the bad.

I find the keypad more difficult to type on than my BlackBerry. I’m sure a good part of this is due to a protective plastic case that covers my keyboard, but the keys do seem a bit closer to each other than on the BlackBerry. Text messaging on the Treo is better than my LG phone due to the QWERTY keyboard…obviously.
The ergonomics and look and feel of the device and applications lack appeal. A good example of this is the Contacts, which is just a black and white listing of all contacts in the directory. The touchscreen feature works well if I use the stylus, but is marginal if I try to use my finger. I don’t really mind the stylus, but I’m always worried that I’ll lose it. Not so much with my finger. I’d think that a few UI and usability tweaks would go a long ways toward improving the aesthetic appeal of the device. As Neal stated during a conversation at the Green Bay NoFluffJustStuff symposium…”it’s so Phone 1.0″. True.
Overall reliability hasn’t been terrible. Essentially, the phone works exactly as advertised, but unfortunately, with a few tweaks, it could work so much better. The boot loop and tethering issue are two examples.
Performance is choppy and delayed at times. Attempting to access the web via Blazer or hanging up a call are two instances where the phone tends to lock up for a moment, causing some minor annoyances.
Interoperability between applications isn’t great. At one point, I tried to impress a friend by accessing a webmail account and downloading a word document that had been sent. While I’d never tried it before, I figured since the phone came with Documents to Go, it’d be easy to download a Word document and open it. Unfortunately, I couldn’t figure out how to save the .doc file, and when I clicked on the link, the Treo 700p opened it up showing nothing but a bunch of binary garbage. Why wouldn’t it just send it to Documents to Go? Don’t know. My friend was not impressed.
Many folks complain about the feeble storage capacity on the Treo 700p, with only 128MB. Since I use my iPod for music instead of pTunes (and I don’t listen to music other than the radio all too often), storage isn’t a huge issue for me. I purchased a 2 GB SD card, and I suspect that’ll be plenty for me well into the future. I could be wrong, especially if I begin to load my Treo with custom applications. Of course, I can’t imagine increasing the storage capacity of the Treo would be a significant undertaking for Palm, and the number of users who desire more storage should serve as a compelling enough reason to do so.

And the ugly.

Ah yes…the dreaded boot loop. For no apparent reason, the phone gets caught in an endless boot loop where the screen shows the “Access Powered” logo following by a startup screen followed by the “Access Powered” logo followed by a startup screen followed by the “Access Powered” logo followed by…ok, you get the picture. The only way to correct this nasty little bug is by performaing a hard reset, which in turn results in total data loss and restores the machine to it’s original state. The first time this happened, I freaked because I hadn’t done a hotsync recently. While a warm reset allowed me to backup most of my data before performing a hard reset, I immediately purchased BackBuddyVFS to hopefully avoid future loss of data concerns. It hasn’t happened again yet, but when it does, I’m hoping BackupBuddy makes recovery easy. Regardless, this is a serious issue, and not one that users of a well-built device should be worrying about. Fortunately, it’s only happened once over the past month of usage.

Overall, save for the few ergonomic and UI quirks, minor instability issues, and the dreaded boot loop, I’ve enjoyed the phone. Camcorder, tethering, and Mac integration were important features for me. My BlackBerry/LG setup had none of these (possibly newer BlackBerry models have some), Obviously, the iPhone fits the bill with great Mac integration. The iPhone appears to be an amazing device, and as it evolves, I’m sure my interest will increase. To this point, as a replacement for my LG and BlackBerry, the Treo 700p is working nicely.

@kirkk.com blog: Agile 2007 Recap

Thu, 23 Aug 2007 03:31:02 +0000

A bit later than I had hoped, but I wanted to take a moment to reflect on Agile 2007 in Washington, D.C. last week.

I arrived at Agile 2007 on Wednesday, midway through the conference. After a few conversations with attendees , I’m certain I’ve captured the essence of the conference. Immediately upon arrival, I jumped right into the second half of a panel discussion focused on Agile Portfolio Management. Then last night, I was invited to an Agile Roundtable discussion hosted by the fine folks at Stelligent, where a significant portion of the conversation centered around agile adoption and transition. You can obtain an overview of the discussion in this eWeek article. Thursday, I attended two different sessions. The first discussed The Enterprise and Scrum, and the second focused on Agile in the Waterfall Enterprise.

Therein lies a major theme of Agile 2007 - agile transformation and agile adoption within the enterprise. It seems that the majority of speakers and attendees I’ve spoken with who have agile experience are Scrum masters, agile coaches, or agile mentors looking for better ways to bring agile to the enterprise. For instance, conversations that emphasize vendor integration and COTS software packages typically turned toward contract and vendor relationship management. But as a developer, my area of interest lies more with strategies related to testing an application that integrates with a COTS package, and the infrastructure required to support frequent deployment of a COTS package. Not that we need another session on testing… But seriously, we cannot forget the developer within the agile enterprise. Some ideas for great developer sessions that come to mind include choosing an agile technology stack, principles for increased architectural agility, and tools for an agile infrastructure. Maybe next year.

Of course, with that said, Agile 2007 appears to have been a smashing success. It was sold out well in advance, and the enthusiasm of the crowd was tremendous. The conference felt small and personal, which allowed for a high degree of interaction between the speakers, vendors, and attendees. Hallway discussions were frequent and intense. But after spending some time speaking to the folks in the trenches, I share their opinion…more content discussing agile development techniques would have made the conference even greater. After all, the developer produces the one [and only] artifact that truly matters..the source code (pssst…don’t forget that).

Now, onto SD Best Practices in Boston.