Feeds:
Posts
Comments

Colonel John Boyd was a United States Air Force fighter pilot and self-taught scholar.  A true polymath, he mastered a wide range of subjects from dogfighting to physics to philosophy.  Boyd was the best kind of thinker; a theorist as well as a practitioner.  His thinking influenced US fighter jet design and military operational art and science from the 1970’s up to the present.

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.

Interesting Links

  1. What is OSGi for?? by Neil Bartlett
    An explanantion why OSGi is useful.
     
  2. Terracotta Server as a Message Bus by Mark Gregory Turansky
    Interesting idea outside the conventional solutions.
     
  3. Patterns in Real Life By Boby Thomas P
    Using real world objects to explain design patterns.
     
  4. The End of an Era, the Beginning of a New One by Sébastien Arbogast
    Will the OOP paradigm be supplanted?
     
  5. Developing Expertise: Herding Racehorses, Racing Sheep (presentation) by Dave Thomas
    What nurses can teach us about expertise.  
     
  6. Interview: Mary and Tom Poppendieck on using Lean for Competitive Advantage
    The Poppendieck’s discuss Lean thinking and what it means for software development.

Ruby on Rails

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.

OpenEjb in Felix

The first post of my blog was about OSGi, a java technology that has gained some traction.  As part of my OSGi education, I’ve been reading blogs, articles, and playing around with Apache Felix.

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:

Continue Reading »

Booch on Software

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

When I was in grad school, one of my engineering professors stressed the need for humility when doing any science-based endeavor (I would add any endeavor, actually).  Contrary to conventional wisdom, scientific knowledge is not static; it is dynamic.  Scientific knowledge is continually revised over time in light of new evidence.  Because engineering is a scientific process, this dynamism applies to building things as well.  How does scientific dynamism relate to the virtue of humility?  We should be ready to throw out any conclusions or designs that mismatch with new data.  Humility facilitates this process. The authors of Head First Object-Oriented Analysis & Design (pg. 246) state it another way:

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.

OSGi

Something I’ve been researching lately is the Open Services Gateway Initiative (OSGi) framework- a java module system.  I think it probably holds some promise as a viable technology, although I remain agnostic due to my lack of “real world” experience.  Regardless, at some point most java developers will be exposed to OSGi in one way or another.  More than a few industry heavyhitters are adopting it.  Heavyhitters like Eclipse, BEA Weblogic, IBM, JBoss, and Oracle.  It may even become part of Java 7 if JSR 277 is adopted.

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