We’re just back from a fantastic weekend in Yosemite, where we hiked Half Dome (Google Search, Google Earth link). If you haven’t already, I strongly suggest installing Google Earth and clicking on this link: the 3D view of the Dome is absolutely gorgeous (and remember you can tilt the view with Shift-Arrow Up/Down).

Unless you live in California, you have probably never heard of Half Dome. It’s not the highest peak in Yosemite Valley, but it’s famous for the hike that leads to its top, which is also said to be the most difficult in the entire park.

Here is the outline of our hike:

• Total distance: 17 miles.
• Vertical gain: 4800 feet.
• Total time on the hike: 13 hours.
• Quantity of water consumed: about a gallon.
• View from the Spring Board on top of Half Dome: jaw-dropping.

Fortunately, there are several stages along the way that make the experience quite rewarding, even if you decide to turn around before you reach the top:

• After the first 1.5 mile, you reach Vernal falls, which towers above the Happy Isles while giving you a good idea of what a vertical drop of gushing water can look like.

• 2 miles later, you arrive at Nevada Falls, which is just a bit higher than Vernal Falls but offers an equally stunning view of the valley and a vertical drop that will make you dizzy if you lean forward too much.
• The next 4 miles meander through Little Yosemite Valley and are fairly flat. This section allows you to walk around Half Dome in order to orient you toward the side that can actually be hiked (the side that is facing the valley is a vertical drop that attracts rock climbers from around the world).
• The mile that follows starts going up more severely, but the beautiful pine trees and occasional view of the valley below give you a good reason for stopping and catching your breath.
• Then you arrive at the bottom of Half Dome and you are facing your next challenge, sometimes referred to as “Quarter Dome”. It’s a series of very vertical steps carved inside the granite that allow you to climb over the first hilly part of the Dome. This section in itself would be enough for a casual hike, and it certainly got all of us out of breath by the time we reached its top.
• And finally, you’re at the bottom of the Dome. By then, you only have about nine hundred vertical feet to overcome to reach the top, but the incline there is above fifty degrees, so a pair of metal cables have been drilled into the rock to allow climbers to get through this last section. It’s imperative to bring gloves with you or depend on the kindness of strangers who would be willing to part with theirs (it’s actually quite common). This part of the hike is not the hardest per se, but it will certainly put your vertigo sense to the test, especially when you climb it down (hint: do it in rappel. It’s not just that it hides the scary sight of the void beneath, it just makes the climb down much easier).

The hike is certainly strenuous, but nobody in our little group can even be remotely called a hiker. Yet, we pulled it off, and with us, dozens of other courageous hikers of all ages and fits that we saw along the way. Don’t let this description intimidate you, this is something that everyone should do at least once in their life.

An unforgettable day.

It’s interesting to see that the Design Patterns book has been coming under mild fire lately. I say “mild” because what I have seen so far is more of a criticism than an all-out attack.

Over the past year, I have been giving a presentation called “Designing for Testability” in which I offer a few recommendations and observations on what a developer needs to do to make their code more testable.

When I started thinking about this topic, I was surprised to realize that some of the guidelines that one needs to follow in order to make one’s code more testable are directly at odds with some principles that we have taken for granted for such a long time. The principles under attack come from various areas, such as object-oriented programming and, not surprisingly, Design Patterns such as those described in the book. I’ll list two of these ideas below just to give you an idea, but I’ll save a deeper discussion of what I mean for a future post, since I’d like to make a different point in this article.

Here are some of the principles you need to question if you want to make your code more testable:

• Extreme encapsulation. It’s a good OO principle, but it can make testability challenging.
• The Singleton pattern. While Singletons themselves are not necessarily harmful, their recommended implementation so far — using static methods and variables — usually leads to code that’s hard to test.

Having said that, I think the characterization that “Design Patterns aren’t”, from a presentation given by M. Dominus in 2002, is wrong on many points, as is the more recent follow-up by Jeff Atwood on the same topic.

In this article, I find that the author is doing two questionable things:

• Criticizing Design Patterns without offering an alternative.
• Making a parallel between Alexander’s construction Design Patterns and software ones.

The first point is probable more of a personal one: I highly respect the practice of criticism, but if is not followed by concrete proposals to remedy the problem, I find the attitude very questionable. Like we say, “La critique est facile, l’art est difficile”.

The second point deserves a more lengthy response.

Alexander’s book leaves a lot of room for art and personal creation, which shouldn’t come as a surprise: building is indeed an art, and the final work needs to be both safe and functional and pleasant to the eyes of onlookers, residents and occasional visitors alike.

The part of art in software engineering is, in my opinion, much more restricted. There is only so much beautiful code or harmonious class hierarchies that you can create. Conversely, the foundation of a software architecture must obey a lot of fairly strict rules in order to be solid, maintainable and evolvable.

Criticizing Design Patterns is like saying that the nuts and bolts that keep a bridge together shouldn’t be designed with templates and cookie cutters found in factories, but instead, be more open to the creative thoughts of engineers.

There is a reason why it’s important to establish a clear separation between Alexander’s Design Patterns and the GOF’s Design Patterns: software engineering is nowhere near as advanced as building engineering is. We are still working on these nuts and bolts, and whenever a new software project starts, we still can’t be sure it won’t collapse under its own weight after just a year. To make a parallel: imagine a world where every time a new construction takes place (say, a bridge), the future of that bridge depends on the team of engineers and workers you choose to build it…

Scary thought. It’s a relief to think that while we might still be building ugly buildings and towers, we can be reasonably sure that the engineering principles that underlie these constructions are scientifically sound and empirically proven, and that these building won’t collapse into a pile of twisted metal for no reason.

The reality is that we are still struggling in software to reach this kind of certainty. We haven’t quite invented software nuts and bolts yet, but the GOF’s Design Patterns book is a very good start that no software engineer should ignore. Yes, there is a good amount of cookie cutter recipes in this book, but I see this as a good thing. The more templates we come up with to lay out software foundations, the more software developers will be allowed to focus on aesthetic considerations.

Our software needs to be solid before it can be beautiful.