Skip to main content

Keep the objective in mind

Posted by johnreynolds on April 1, 2005 at 3:20 PM PST

My wife and I are not the most practical people in the world. We live in Austin, which is in central Texas, and my wife’s family lives in El Paso, which is as far west as you can go in Texas (El Paso is actually closer to Los Angeles CA then it is to Houston TX).

Roughly 500 miles west of Austin and 200 miles east of El Paso there is a desert mountain range called the Davis Mountains. Its main claims to fame are the ruins of old Fort Davis and the McDonald Observatory.

We fell in love with this remote mountain range and purchased 18.24 acres on the top of a ridge, the only access to which is a rocky dirt road with several astoundingly steep and twisty switchbacks. It’s an adventure just to get to our property when it’s dry, and if it’s raining you will be taking your life in your hands if you try to get down off the mountain (even with 4 wheel drive). The payoff is a fantastic view.

On top of this isolated ridge that others might call god-forsaken, we’re building a cabin. It’s tough even to get materials up to the site, everything has to come up those steep switchbacks, but I was able to convince a local to deliver two prefab metal buildings (one is 14’ by 24’ and the other is 12’ by 12’). They aren’t much to look at yet, but they’re very sturdy and an excellent base on which to build. Once I’ve encased the shells in papercrete and build some covered porches our little casita is going to be quite delightful.

Thus far, the vast majority of this endeavor has been done remotely, via the phone and email. I’ve never actually met the gentleman who built and delivered the cabins. My communications with him were pretty much limited to a sketch of where I wanted the doors and windows, how I wanted the buildings to relate to each other, and one simple directive:

"Align the cabin so that I can see the McDonald Observatory through the front door."

I am delighted with the results. The doors and windows are not precisely where I want them, but when I sit in the big room and look out the French doors I’m staring right at the McDonald Observatory (the telescopes are the white dots on the far mountain in the picture below).

In our world of software development, simple directives are often overlooked. We often get lost in the minutiae and confuse details with objectives. It isn’t worth a darn if my doors and windows are accurate to the millimeter unless I can see the Observatory.

Kohsuke Kawaguchi’s recent blog entry: "Should JAXB Work With Fields or Properties?" is a good example of how we can lose sight of the Observatory. Kohsuke shares with us a decision that is facing the JAXB 2 development community: Should the default behavior store all of the fields in an object, or only fields that have getters and setters. This is a great question, and Koshuke lays out the options well… I am really glad that he shared this with us.

I don’t have a strong passion for the outcome of this question, but I am passionate in promoting clear thinking. My response to Koshuke was the following:

"Step back and consider JAXB's purpose.
You wrote: "JAXB 2.0 is primarily a persistence technology"
This tells me that the intent of JAXB is to persist a Java POJO... in this case the persistent form is an XML representation, but that doesn't really matter.
As a "persistence technology", JAXB's reason for being is to be able to store an object, and then restore it later to the same state.
Ask yourself the question: Do the properties of the object dictate its state, or do the fields of the object dictate its state?
Answer that question and you'll have the answer to your question."

Beyond the answer to Koshuke’s question lies another interesting question. If there is controversy on what the default behavior for JAXB 2 should be, then is it meaningful to have a default behavior at all?

Over the years I have fallen into these traps repeatedly. My colleagues and I endlessly debated questions based on what we did at previous jobs or whether or not it was easy to implement one solution over another. We often forgot to step back and ask:

"What was the objective?"

With JAXB the objective is pretty clear; provide a Java to XML persistence technology. All decisions on details must defer to that objective.

Amazingly, we’re back to communicating with our customers. We’ve got to really understand what our customers want and what our customers expect. We can’t do that unless we have a glimmer about how our customers think. If we aren’t sure what most customers expect, then we cannot provide “default behaviors”.

My contractor in Fort Davis understands why people want to build cabins on top of remote mountains. They love the view. It’s tremendously important to build a structure that can survive the high winds and temperature extremes, but it’s the view that’s going to determine success or failure. I’ll bet he would have lined up my French door with the Observatory (the best view) even without my directive.

The JAXB development team is actually pretty lucky. Most of them plan to use JAXB themselves, so they can empathize with their customers. It’s not so easy when your customers are business people who aren’t technologists.

(Cross posted at The Thoughtful Programmer)

Related Topics >>