I was shy of the year anniversary of construction by a few months. Whew! The tree fort, which resembles more of a playhouse, turned out exactly as envisioned. And, I learned software engineering and house construction have some similarities and some distinct differences. In the last few work sessions I experienced the most valuable similarity between the two disciplines: hire an expert!

In a recent post concerning Java One, I discussed Ben Galbraith’s rule of hiring a designer. In the actual construction of the fort, his sediment echoed loudly. I grossly underestimated the need for experienced help. Actually, I underestimated the importance of a square and over estimated my ability to carry 8ft sheets of plywood and lift them 6 ft above me. But even more importantly, I am a total n00b with working with wood. Luckily this is not a family trait.

My father drove all the way from Savannah two weekends in a row to help me erect and complete this pet project. Since he’s done similar construction projects in the past, he knew all of obstacles to avoid. He, also, knew what needed to be planned and what could be fudged. Most of my time in the past had spent deliberating on the “right” way to proceed. Dad was a constant momentum forward. Having an experienced person is invaluable.

Below are pictures of the project. The fort is primed and ready for painting and the finer finishing.



May 29, 2008

The movie was pretty blah for me personally. Typical Academy candidate quality as of late. In fact, I’d probably would have rather watched An English Patient again than see Keira Knightley in yet another period piece. However, what is interesting is obvious, yet deceptive, play on the definition of atonement. The movie ends with the author’s definition. As a movie watcher, I experience the definition rather being explicitly told in black-and-white text.

I wonder if I could so exactly express a moment/experience/situation as a model definition.

Spring is in full force in Georgia. We had a battle with intermiddent cold spells. But with a pleasant Memorial weekend, the unfinished Tree Fort was beckoning. Last weekend, I attempted an untimely addition. My daughter has been patiently waiting for a swing set. The plan was to finish the fort and then add the swings. But, she’s too cute to ignore. I took a weekend to plan out the extension. My wife and I looked at some online plans, went to a couple of home depots, and selected the materials to use. A few bruises and bolts later we had our swing set ready to go.

Of course, the first design is never the best design. Just like in programming – you use the limited amount of information at hand and build with assumptions. With a swing set, the models used either a (1) 4 X 6 or (2) 2X6 for the beam. I had trouble finding a good connector to the tree for the 4X6, so I elected for (2) 2X6. I bolted them together for extra support and used a connector to the tree. On the models, the swing set is traditionally 8ft long. (2) 2X6s can handle the swing leverage at 8ft. At 12ft long (my design), the beams tend to bend more. One adult or two excited kids can make the beam wiggle like a rubber pencil. I find this out after I am completely done and admiring my handy work. Ugh!

So although way within woods stress thresholds, I decided to refactor the swingset. Now, in software engineering I would check out the existing version. I’d make my changes. Tag the source code. Check it back into my repository. Retest. And, then push it into production. A simple not so labourous process. Tree forts and swing sets follow the same process except “make my changes” involves completely disambeling the existing. More labor. More bruises. More expletives.

Nails, when hammered into an object, generally are put there not expecting to come back out. In fact, the whole reason you hammer them in the first place is to ensure they will stay there. “Keep this board attached to this other board” is the sole purpose of a nail. If you want to fasten something and are unsure if it should stick, use a SCREW! I spent an hour or so digging out frack’n nails. This is not fun with 50 pounds of boards which you are trying to take them apart strategically as to not have them come crashing down upon your son 11 ft below. Luckily the fall was well designed with me catching the brunt of the wood as I fell off the ladder. I hate ladders. Billy and I decided I should continue the disassembly alone.

Once the pieces were on the ground, reconstruction went pretty well. Tisha helped keep the boards from tumbling back on me while I propped the A frame back up. All in all, the 4X6 was heavy but easy. And, the beam is much better at handling the G forces of my two kids swinging the spring away.

A couple of weeks have pasted since my trip to JavaOne 2008. Although the trip was overall informative, only a few session continue to resonate. The few sessions I commented on have either personal or professional relevance; more so, they are worth futher discussion long after the excitement of the conference has faded. Compelling User Experiences by Ben Galbraith is one such session.

The Compelling User Experience presentation provided a rule set for delivering high quality user applications. Ben outlined his own methodology for managing high user expectations. He cited various industry experts to support his criteria. Examples of good and bad applications were shown. The plot of the presentation was very traditional. However, the presentation itself was remarkable.

Ben’s presentation was the only presentation, in all of my sessions, where I wanted the deck itself. The presentation echoed the rules he puts forth. Ben did not simply put a bunch of bullets with text on the screen. His discussion expanded upon the slides. He did not simply read what was shown. He used images and appropriate visual effects to reinforce information. He did overburden attendees with huge amount of text on a slide. His presentation lends much credence to his talk.

This is very different than the other technical talks I attended. Most of the presentations gave a bunch of bullet snippets and a demo slide. Talk, blah, blah, demo, blah, conclusion. If you want to inspire me to use your library, platform, or tool, then give an inspirational presentation. Show me the appeal. end-of-rant.

From my notes on the session, Ben has 4 rules to creating a compelling user experience.

#1 Get to Know Your Users

What are the user’s expectation for the application? Understand, a user may change their expectation during the course of development or the product’s life cycle. Different users may have different expectations. A back office clerk has totally different expectations than a Senior VP. Key to knowing your users is to focus on their tasks? What are they trying to accomplish by using your software?

#2 Ignore Your Users

Pay attention to your user base but don’t let them design the software. Ben cited 37Signals mantra of ignoring users until you see a reoccuring and persistent compliant. Instead of directing all your effort in making the application work for the few “squeaky wheels”, focus on improving the application to serve the intended purpose.

#3 Visual Design and Interaction Design are distinct, related, and important

“Attractive things work better”. Ben stressed this point. All industry experts will tell you the universal fact: sex sells. Even with the applications, a more visual appealing interface is used more often than a more feature full app. He gave a trival reference to a study conducted showing users prefer a less stable but more appealing application to another more stable app. The reason is an intate human characteristic. Appealing applications make people feel good about using them. Look at Apple for a case study.

#4 Aesthics matter

I have little notes on this item. Hopefully, I’ll get the deck and can expand on this subject.

The remain portion of his presentation discussed tips and rules for building an appealing application.

Visual Design Tip

Hire a designer. A true application designer, not a programmer who fills the role. Fashion matters and designer live and breathe fashion trends.

Interaction Design Tips

Don’t make the user wait! Response time should be 0.1 seconds for most interactions. At 1 second, users become distracted.

Input is sacred. Auto save user data in every scenario possible. Prefer undos to warning dialogs. With a web application this is difficult to accomplish. However advances are being made in audit table constructs to show previous states of form inputs and session states. The audit table is similar to the Time Machine implementation in Apple OS X. A user should be able to go back to any previous state via a timeline.


“Best to market is not first to market” Applications selling are not often the first to market. This is not to say you can wait 6 months to launch. But, developers should strive to build the best, most appealing, application to achieve sucess.

I was very impressed by Ben. I hoping I can arrange a net meeting/presentation to my team at work. His topic echoes some of my same sediments and discussion with my team. Enterprise IT lags extremely behind in building compelling applications. Our development groups are faced with incredibly agressive timelines that do not support aesthics. But, if I can instill some of Ben’s ideals perhaps we can slide a few tips and impress our users.