One of Boyd’s mantras was “People, Ideas, Hardware. In that order!”.  Investment in people is paramount. A perennial engineering temptation (naturally and understandably) is to focus on the technology (aka hardware).  A great programmer will produce results regardless of the language (Java, C++, Scala, Fortran, Cobol, future super cool language X, whatever).  Technology does not a software developer make.

The “people over technology” theme can be illustrated by a study of the past.  Because the past is truly prologue and history has useful trans disciplinary lessons for us, behold the Russian T-34 tank:

First developed in the late 1930′s, the T-34 was a revolutionary design.  It would have a huge influence on tank development that resonate today.  When the German Wehrmacht (Armed Forces) first encountered the T-34 in Operation Barbarossa in the summer of 1941, the T-34 was a shock.  Superbly well-endowed with thick, sloped armor, a deadly 76.2mm cannon, and a powerful 500 hp diesel engine, it was everything its tank peers were not.  Typical tanks of the period (including German) had thinner, unsloped armor, small caliber cannon, and easy-to-catch-fire gasoline engines.  For the technology uber-alles crowd, the Russian army should have swept the field of its adversaries in the last half of 1941.

History records a much different result.  The exact opposite happened.  The Russian army incurred devastating losses of men and material and was thoroughly routed.  Better technology did not and could not save them*.  The German army of 1941 had superior people (better trained and experienced), strategic/tactical ideas, and leadership.  Their technologically inferior armored force did not impede their success.  This example from history can be applied, albeit loosely, to the modern battlefield of software development.

Boyd’s emphasis on people is something I try to remember, especially when a new and exciting technology appears on the horizon.  Technology alone will not save your project.  Hard, diligent work coupled with sound design principles (separation of concerns, DRY, decoupling, etc.) are the most important things.  As long as they remain in focus, have at it with the technology, old or new.  As an added benefit, the essentials above will make your technology choice decisions informed and wise ones.

A book** I’ve reading lately supports Boyd’s maxim.  After recapping some of the author’s hard-won experience with successful software architectures, they note that “Success is not based on the technology”.  People and ideas are more important.

Of course, good people + good ideas/process + good technology is ideal!

* In the utterly ruthless feedback chamber of WW2 Eastern front warfare, the Russian personnel and strategic/tactical ideas would learn and adapt and ultimately, of course, win the war beside their American and British Commonwealth allies.

** M. Rosen, B. Lublinsky, K. Smith, and M. Baker, Applied SOA, Wiley Publishing, Indianapolis, IN, 2008, page 10.

I was having a discussion several days ago with a colleague about Ruby on Rails.   As a Struts veteran, I found it to be a revelation.  Keep in my mind, however, my only “hands on” experience is the ONLamp.com tutorial Rolling with Ruby on Rails.

In 2005, I was on an overseas assignment and asked to throw together a reporting web app several days before my departure.  I did what I knew and that was Struts.  Bear in my mind, I like Struts, and it was a good MVC implementation in its day.  I’ve written many a Action and form classes.

I completed my Struts web app before I left.  It was a decent, if rushed, bunch of CRUD web pages with a truly awful GUI frontend.  I just didn’t have the time for CSS, nice buttons, etc.  All my time went into wiring the stack together and getting the basic functionality completed.  At the time I didn’t realize the  infrastructure overhead required.  Was it alot? Not really, but I was reinventing the wheel again as I had with other Struts apps, past, present, and future.

As I went through the Rolling with Ruby on Rails tutorial about 18 months later,  I kept thinking back to that crude CRUD Struts I had written a long time ago, in a galaxy region far, far way.  The “convention over configuration” paradigm used in RoR would saved alot of time.  All the time I spent on the “plumbing” in my Struts app, I could have used to add extra features and make the frontend “pretty” in RoR.   Now I am definitely not a Rails guru, but my overseas web app assignment was the perfect scenario for Ruby on Rails because it highlighted its strengths.  Those strengths include fast delivery of the 80% of features most developers need, mainly CRUD operations.  I know RoR is not a silver bullet, but in it’s niche, Rails excels.  And it’s fun too.

I don’t know where it resides today on Gartner‘s hype cycle, but I like it for what it does.

I think the “convention over configuration” paradigm has some merit.   Its being leveraged by other cool projects out there like Adhearsion (which, I believe, was influenced by Rails).  I hope to incorporate it in future projects that require extensions.   Done well, it has the potential to increase productivity and reduce defects.

Some links:
Ruby on Rails
InfoQ Article “Ruby and the hype cycle“
Top 12 Ruby on Rails Tutorials
Agile Web Development with Rails, 3rd ed. by Ruby, Thomas, and Hansson

UPDATE: After listening to the podcast Java application development in ’08 by Jay Zimmerman of No Fluff Just Stuff, Grails is also a compelling alternative.  Grails takes the philosophy of RoR and puts a JVM-based spin on it.   It combines Groovy, Spring, Hibernate, Jetty, and Gant (I’m sure there are others).  Regardless, I’m glad I played around with RoR as my experience with Ruby was nil.   On a related note, Jay Zimmerman reports that he sees a diminished interest in Struts (with increases in Spring and Hibernate, unsurprisingly).  The podcast is worth your time.  I went to a “No Fluff, Just Stuff” event in Dallas several years ago and I really enjoyed it.  Given the opportunity, I’d go again.

Currently I’m spending some of my free time working on an OSGi project as a learning tool.  The code examples I’ve found have been nice but all do the same thing: a client bundle calls a service bundle in an Activator start method.  End of story.  This is great as a “Hello World” introduction,  but I’d like to see how bundles operate in a way that reflect a real environment.  Thus I’m trying to figure it out myself in a coding “live without a net” exercise.  The project is an attempt to run a legacy enterprise javabean (EJB 2) in an OSGi Felix container.  Yeah, I know EJB 3 is light years ahead but I sometimes have to work with the older spec at work.  Besides, an EJB 2 OSGi bundle maybe just the demo needed to sell OSGi in my shop.

I’ve found Apache’s OpenEjb project and started there as it advertises a port to OSGi.  The core jars are bundles.  Second, I used OpenEjb embedded in Tomcat web server at a Valtech EJB 3 course and walked away impressed.  What follows is a way to get OpenEjb running in Felix.

Caveat Emptor:  there may be a better/simpler/elegant way to do this.  I’m an OSGi and Felix neophyte and your results may vary.  BTW, this example was done on Windows XP.

Here’s how I did it:

1.  I followed the Felix setup tutorial for Eclipse.
2.  Add the <openejb home>/lib jar files to your Eclipse project’s classpath.
3.  In your Eclipse project, click on the conf -> config.properties file.
4.  Edit the org.osgi.framework.system.packages properties key by appending the following packages:

\
 javax.annotation.security; \
 javax.ejb; \
 javax.ejb.spi; \
 javax.interceptor; \
 javax.management.j2ee; \
 javax.persistence; \
 javax.persistence.spi; \
 javax.mail; \
 javax.resource; \
 javax.resource.spi; \
 javax.resource.spi.endpoint; \
 javax.resource.spi.work; \
 javax.security.jacc; \
 javax.wsdl; \
 javax.wsdl.extensions.http; \
 javax.wsdl.extensions.soap; \
 javax.wsdl.factory; \
 javax.wsdl.xml; \
 org.apache.commons.cli; \
 org.apache.geronimo.connector; \
 org.apache.geronimo.connector.outbound; \
 org.apache.geronimo.connector.outbound.connectionmanagerconfig; \
 org.apache.geronimo.connector.outbound.connectiontracking; \
 org.apache.geronimo.connector.work; \
 org.apache.geronimo.transaction.log; \
 org.apache.geronimo.transaction.manager; \
 org.apache.log4j; \
 org.apache.openjpa.event; \
 org.apache.openjpa.persistence; \
 org.apache.xbean.finder; version=3.4.0.r636442, \
 org.apache.xbean.naming.context; version=3.3.0, \
 org.apache.xbean.naming.reference; version=3.3.0, \
 org.apache.xbean.recipe; version=3.4.0.r636442, \
 org.codehaus.swizzle.stream; \
 org.hibernate; \
 org.hibernate.transaction; \
 org.objectweb.asm; \
 org.objectweb.asm.commons; \
 sun.misc;

5.  In the same config.properties file, look for the felix.auto.start.1 property. Append these OpenEjb bundle entries:

\
file:C:/<openejb home>/lib/openejb-jee-3.0.jar \
file:C:/<openejb home>/lib/openejb-loader-3.0.jar \
file:C:/<openejb home>/lib/openejb-javaagent-3.0.jar \
file:C:/<openejb home>/lib/openejb-core-3.0.jar
\

Make sure to replace <openejb home> with the path to your OpenEjb installation.

6.  Run your Felix Eclipse project per the instructions in the setup tutorial.  After the Felix OSGi container initializes (hopefully successfully), type “ps” to list your installed bundles:

START LEVEL 1
ID   State         Level  Name
[   0] [Active     ] [    0] System Bundle (1.0.1)
[   1] [Active     ] [    1] Apache Felix Shell Service (1.0.0)
[   2] [Active     ] [    1] Apache Felix Shell TUI (1.0.0)
[   3] [Active     ] [    1] Apache Felix Bundle Repository (1.0.0)
[   4] [Active     ] [    1] openejb-jee (3.0)
[   5] [Active     ] [    1] openejb-loader (3.0)
[   6] [Active     ] [    1] openejb-javaagent (3.0)
[   7] [Active     ] [    1] openejb-core (3.0)

Again, there may be a better way to do this but the above worked for me.  Also, by adding the OpenEjb bundles to the felix.auto.start.1 property, I don’t have to continually restart those bundles when debugging my EJB 2 test bundle.

I can’t get my EJB 2 bundle to work with OpenEjb; my current issue is JNDI lookups.  Once I figure that out (probably by using the OSGi service registry?), I may post my results if its not too much of a hack.

Update:  The EasyBeans project has a tutorial on how to EJB and OSGi to play together.

The task of the software development team is to create an illusion of
simplicity.

We build abstractions to create this illusion.

Grady Booch

Standards make innovation easier because they make the results of innovation more widely available.
Stephen F. DeAngelis

Pride kills good design

So too should we engineers acknowledge that our designs should evolve and adapt (especially at the outset) as we learn and discover more about the problem space.  The fact is humans simply cannot comprehensively understand a new domain.

Being humble before an engineering problem, like an enterprise application, acknowledges what my professor called the Axiom of Specification. This engineering law states the following:

The human cannot correctly specify (abstract design) at once all levels of a system at the outset of its development.

The stinging hand of experience has taught me that my initial software designs weren’t very good.  I simply could not wrap my mind around a engineering problem in toto upon first exposure.  The Axiom of Specification was in full effect.

The Agile and Lean paradigms take into account this axiom.  For instance, iterations deliver feedback allowing engineers to alleviate the knowledge deficit at the beginning of development.

So stay humble; don’t be “married” to your design, continually investigate your problem domain, and be ready to change your designs as you learn.  You can’t subvert the Axiom of Specification.

Here’s some links:

The OSGi Alliance
Neil Bartlett’s Getting Started with OSGi tutorial is a good place to start. (He’s also started a free book that’s worth checking out.)
Eclipse’s Equinox – probably the most popular implementation
Felix - Apache’s implementation
Spring Dynamic Modules for OSGi
An Introduction to OSGi on the Server Side – article published by BEA Systems Oracle