In addition to technical geekery and social commentary, one of my favorite intellectual pursuits is the study of military history. It’s one of my many interests that makes me so very thankful that I met my wife when I did or I would never have had a date in my adult life.

I am not a pro-war person. Anyone who reads good military history will often find that the best historians are quite anti-war. I had the opportunity to see Rick Atkinson speak in Seattle last winter as he was promoting his book, Day of Battle. He has written several titles about both WWII and Iraq and said that all of his books as anti-war and hopes his readers understand that. No historian has summed that notion up as well as John Keegan in his introduction to The History of Warfare.

To study war is not necessarily to glorify it. To be sure, a good bit of the military history bookshelf is filled with martial hagiography (see Ambrose, Stephen), but to those who study the history with more than a simple fascination of the technologies and armies there is a rich depth of human experience and tragedy to explore.

Like most men (and I’m sure that 99.9% of all military historians are male), I began with that very boyish fascination with all things violent and martial. As I grew older I realized that this was a silly childish interest. I either needed to stop reading about this subject, or I needed to understand it better. I chose the latter in an attempt to cull meaning from so many centuries of meaningless slaughter.

Humans go to war for a variety of reasons–most of them not good. Greed, hatred, and lust for power have fueled more than their fair share of conflict and tragedy. However that doesn’t mean that I think all war is useless. There are some things worth fighting and dying for, but those moments are few and far between in human history. While I cannot condone military action in most of the cases in which it occurs, I believe that it is an inevitable part of the human experience. We were simply bred to beat each others brains out. This is a depressing and tragic conclusion, but I believe that human history is on my side when I make that statement.

So what’s the point of reading military history? If all we are going to do is make the same mistakes over and over again what possible good can from studying the past? Despite my pessimistic outlook on the short-term chances of humanity straightening itself out, I think in long-term we may learn from our mistakes. Military history is nothing if not a study of mistakes. Yes the Hannibals, Napoleons and Pattons of history get the accolades, but there isn’t nearly as much to learn from their successful campaigns. We need to look at the spectacular failures too.

For example, we can learn far more from the fateful decisions of both Napoleon and Hitler to campaign in the Russian winter. While the technical reason for their defeat was weather and logistics, the true cause of their downfall was hubris. It wasn’t that neither failed to comprehend the risks, but rather they felt that their leadership and the elan of their troops transcended reality. Can anyone else think of a recent example where a leader ignored the facts on the ground in pursuit of their own personal policy? Hmm? Anyone?

Another fine example is the book I’m currently reading, Mr. Atkinson’s aforementioned The Day of Battle. The Italian campaign is an oft-forgotten part of World War II. This is due in no small part because there was very little to celebrate in that campaign. No gutsy fortitude like Guadalcanal or Stalingrad, no tragedy like Poland or Saipan, just lots of dumb decisions that required a tremendous amount of cannon-fodder to achieve victory.

Few campaigns offer such a textbook example of group-think gone horribly wrong as the Allies in Italy during World War II. From Churchill and Roosevelt, to Eisenhower, to the theater commanders, everyone in the chain of command was eager to cast what they saw with their own eyes in terms of what they desired, not what the actual realities on the ground were. While we may not be in a war in our day-to-day work, each of us can certainly come up with examples where group-think led everyone to bad conclusions.

The other valuable outcome of studying military history to come to a better understanding of just what the cost of war truly is. Obviously anyone who has not experienced combat cannot imagine the horrors of that experience. I thank my lucky stars that I never had to go to war. But I feel that it’s disingenuous to rail against the horrors of war without making an attempt to understand them.

I attended the University of Oregon and there are few places on earth that have a stronger innate anti-war bias. I have no problem with the pursuit of peace, but to do so in ignorance serves no one. It’s vital that we all understand what the consequences of going to war are. I fear that the cavalier attitude with which the United States has prosecuted the Iraq War and insulated the public from the horrifying facts on the ground only serves to keep us ignorant of the true costs of war. This is not a game of cops and robbers–people are dying daily for questionable causes, to say nothing of the long-term political consequences. But I digress…

One final reward of the study of military history is to recognize how leadership within a corporate, in the purest sense of the word,  setting can work. I don’t mean the famous generals such as Grant, Lee or Washington. Rather, a kind of leadership that few successfully execute consciously. Instead it is the Joshua Chamberlains of the world that provide insightful, meaningful case studies of what true leadership is. Most of us don’t work in groups of one thousand or more, but instead in “squads” of ten or less people. Learning how Captains and Sergeants command, push and prod their troops and maintain esprit de corps is worth the time of anyone who is interested in exercising any form of leadership.

It’s rare that at the end of a good military history read I don’t feel the need to weep. Maybe I’m a sucker for heartache but I can’t help but feel just a teeny bit smarter after turning the last page of a well-written piece of military history. So before parting, let me leave you with a short list of great military reads (in no particular order) that I’ve come across over the years:

1. The Peloponnesian War – Thucydides
2. The Civil War (Trilogy) – Shelby Foote
3. At Dawn We Slept – Gordon Prange
4. Just about anything by John Keegan
5. The Best and the Brightest – David Halberstam
6. We Were Soldiers Once…And Young – Harold G. Moore
7. The Rise and Fall of the Great Powers – Paul Kennedy
8. Diplomacy – Henry Kissinger

This week I stumbled upon Stephen Celis’ awesome bit of shell-fu, gemdoc, which allows you to quickly get to the HTML docs for installed gems via command-line. Unfortunately I abandoned bash years ago for zsh and Stephen’s shell bits needed a little porting. For me, zsh, is a bit like swiss-army knife where about 95% of it is a mystery to me, but the 5% I use I couldn’t live without. So simply switching back to bash is a no-go.

My setup is little-bit complicated, but I believe the following, stripped-down, recipe should work:

GEMDIR=$(gem env gemdir)
OPEN=$(whence xdg-open || whence open)

gemdoc() {
  ${OPEN} $GEMDIR/doc/`$(which ls) $GEMDIR/doc | grep $1 | sort | tail -1`/rdoc/index.html
}

_gemdocomplete() {
  reply=( `$(which ls) $GEMDIR/doc` )
}

compctl -K _gemdocomplete gemdoc

Update 6/25/08-10:30: Updated to work for both Penguins and Macs.

I’ve spilled a lot of (virtual) ink in this blog, but almost none of it about what I do all day. That’s because I’ve been working at a startup in “stealth mode” for darn near two years and haven’t been able to really say much about it. Until today.

Today at Evri we’re launching the beta version of our site. If you head to the home page and signup, you’ll get yourself a free set of brand-new shiny credentials that will give you the keys to data-surfing heaven.

The company blog post does a good job of highlighting what we have available, but for the truly lazy I’ll give you the quick highlights.

First, is the home page which gives you a look at entities and their relations as we understand them currently. We start out with lists ranking the top people, places and things. In addition to popularity, you can also see who is rising and falling in popularity over time. All of these lists are clickable and enable our super-whizzy widget which provides a nice way of pivoting between entities, all the while getting related content.

This is one of my favorite parts of the product, as it’s really easy to just get lost wandering around from link to link to see how things are related. It’s like a big six-degrees-of-Kevin-Bacon game, except that you can do with just about anything. Part of that link-hopping experience is visiting specific pages about each entity.

Here you can find more detailed content about an entity. Currently these details comes from Wikipedia, but we anticipate adding several other specific sources of structured content. And of course, these pages link you to other pages, so between the hub-and-spoke visualization and the detail pages you can spend quite a bit of time just data-grazing.

So take it for a spin and have some fun exploring! Give us your feedback (a link is at the top of each page) and let us know what you like and don’t like. Most importantly, stay tuned. This is just the beginning for us, we have some pretty exciting stuff in the works and you won’t want to miss out.

Things have been a bit nutty the last few days–as they are for any release–but it will be worth it for the satisfaction of finally lighting this candle.

Enjoy!

While on vacation last week, my wife and some friends of ours solved the age-old problem of melting the chocolate and the marshmallow in a s’more. You stuff a chunk of chocolate (we prefer good old-fashioned Hershey’s waxy American milk chocolate) inside the mallow and then toast the entire unit.

Do you see where this is going? No? How ’bout this?

Amen sisters and brothers. Now that’s a properly-melted s’more.

I’ve been on a usability/design kick for about the last six months. Somehow I stumbled across a link to Robert Hoekman Jr’s site which was described as great design books for programmers. I fully recognize the fact that I really don’t have that little spark that good designers have, but I’d like to be better at it than I am. So I’ve been eager to find usability and design books that work for visually-clumsy folks like me. Robert Hoekman’s pair of books, Designing the Obvious and Designing the Moment were wonderful additions to my growing design-for-code-dorks library.

The covers of both books were what initially piqued my interest. Both have very simple white covers. Unlike a lot of design books, this one isn’t about showing off a bunch of pyrotechnics on the cover (see Jenifer Tidwell’s Designing Interfaces which includes a colored version of O’Reilly’s usual animal lithograph). I figured anyone willing to put such a sparse cover on the page was pretty confident about the content inside. I also really liked the fact that the form-factor of both books is smaller than the usual trade paperback and comes in at a very economic 200 pages, or about 1/4″ thick.

Alright, I’ll admit that I was taken in by the author’s use of my favorite font, Gill Sans. I just love this font (it’s the font this blog is set to if you don’t override CSS) because it’s clean and elegant with a minimum–or complete absence–of decorative fuss. Unlike the Pragmatic Programmers or O’Reilly the publisher, New Riders, doesn’t seem enforce a particular font style for their books. Therefore I think it’s safe to assume that the author made a conscious decision to use this font which, at a microscopic level, supports many of the notions of simplicity and cleanliness presented in the books.

Designing The Obvious

His first book, Designing the Obvious focuses on translating from what a user needs to creating workable screen-flows. While I’ve knocked out several smaller design books, I’ve been slowly making my way through Alan Cooper’s seminal About Face in which the concept of goal-oriented design is introduced. Hoekman’s book is the second text I’ve come across that offers a contrasting opinion on goal-oriented design the author calls task-oriented design. Whereas Cooper’s approach is to begin design by understanding a user’s goal within the larger context of their lives or career aspiration, task-oriented design is focused on more immediate desires.

A goal-oriented design might start with something like “Anna is a small-business owner who wants to balance career and family. She needs particular help with payroll for her small three-person company.” A task-oriented design might start with “A user with a small-company must be able to setup employees with a minimum of fuss: perhaps just name, address and social security number”. Hoekman even titles one of his chapters “Understand Users, Then Ignore Them”.

Each chapter is tightly-focused on a single concept and few supporting ones. For example, the chapter titled “Turn Beginners Into Intermediates, Immediately” spends a thrifty thirty-five pages outlining the basic distribution of user expertise (hint: the big fat blob in the middle are the intermediate users) and then enumerating several concrete examples of how to serve the intermediates, how to get the beginners to immediates as quickly as possible, and how to keep the advanced users still engaged.

The ability of Hoekman to outline a concept and back it up with several concrete examples is the real strength of the book. This is not a patterns or recipe book. Similarly it’s not a grand philosophical tome (see Cooper, above). Instead it’s a very practical work intent on getting the ideas across, but leaving plenty of room for the reader to explore on their own.

The fact that he gets such a rich amount of information is such a small package is a testament to the author’s well-thought, lean design approach.

5 out of 5 stars

Designing The Moment

Hoekman’s second title focuses specifically on web application design. Unlike his previous book which is more philosophical and abstract, Designing The Moment is much more concrete. With thirty-one chapters spread out over 220 pages, each chapter is tightly-focused. Those chapters are split up into seven major sections.

The first section is titled Getting Oriented and focuses on getting the user oriented with your site. He delves into how users’ eyes flow over a page, navigation, links and dealing with common web paradigms like tag clouds.

The second section, Learning, provides specifics about getting users “over the novice hump”. This theme was an important one in his first book and here he offers several ways to teach your users about your site.

The third section, Searching, walks you through the pitfalls of search interface design. A common theme in both books is that of a poke-yoka, which means to fool-proof in Japanese. The term was originally derived from Toyota’s Production System which was developed in the ’80’s (note: Toyota is currently kicking serious rear-end in the car biz). Here he uses the term poke-yoka device to mean any mechanism that will help prevent the user from hurting themselves. This is not about treating users as idiots but rather hiding ugly implementation details away from the users if at all possible. For example, you if need users to enter a phone number in a particular format, design a form that makes so that users enter phone numbers in that format. Don’t just give them a text field and then complain when they don’t get it right.

Moving on we get to fourth section, titled Diving In, where we really start to get into the nitty-gritty details of things like media player controls, form layout, wizards, and validation. This is the longest section of the book and meatiest. Again, Hoekman nails the concepts with well-chosen representative examples and solutions.

The fifth section, Participating focuses on the mechanics of features commonly associated with “social-networking” web applications. This chapter ranges from concrete implementation recommendations like how to build user profiles, to more abstract, strategic concepts like how to embrace user feedback and how to channel your most vocal users.

The sixth section, Managing Information, provides some tips on helping users digest your site’s contents. Tips here include how to effectively use syndication, dealing with tags and folksonomies, where drag-and-drop is appropriate and dealing with system notifications.

The final section, Moving On, embraces I concept I first saw articulated in 37Signals’ Getting Real . Don’t build your apps as walled gardens where you make every attempt to keep your users from leaving. This ain’t Vegas you aren’t a casino. Yes, you want to give users another chance to reconsider and you certainly want to know why they’re leaving, but don’t be a jerk about it. This section offers some guidelines for parting ways with your users. I think to design something without this in mind is to the fact that not everyone is going to dig what you’ve built. Let them go easily and don’t make things worse by making parting a painful experience.

I loved this book as much as Hoekman’s first title. Both are handy references I’ll keep nearby.

5 out 5 stars.

When I see a forecast like this, I gotta think that life just isn’t fair sometimes…

When talking about building software, few sentences set off more red flags than those beginning with “it would be nice if..”. I don’t mean some variation of this phrase, I mean exactly this phrase. It’s like those words are a specific code-phrase for “speculative features coming your way!”

What the heck is “nice” anyway? The very language of that statement does nothing more than imply; it makes no assertions and offers no proof. A piece of candy is nice. So are flowers and a new house. But those things all require widely varying levels of planning, effort and cost. So “nice” isn’t a very precise word and certainly fails us when we try to evaluate what goes into our product and what stays on the sidelines for further evaluation.

In a geek-heavy setting, such as my workplace, I often observe this phrase used as a desire to establish authority in a conversation. This happens when features are proposed not so much for their value, but as a way of showing how deep and nuanced the proposer’s understanding of the domain is. For example in a brainstorming session we had recently about new visualizations for rich data structures, a lot of IWBNI ideas were proposed that were fairly baroque and hard to imagine being interesting to a wider audience. In this instance instead of focusing on the goal, making sense of a big pile of information, the exercise turned into a demonstration of various participants’ grasp of market dynamics, web trends and cutting-edge features. You can imagine how useful the final set of ideas were.

Another issue with IWBNI features is that they are often very implementation-focused. For example if you are working on a web service that is consumed by other services, you might want to track usage statistics to generate a regular report to see who is using it. The real feature is tracking usage, but that original need can easily be obscured by an overly-specific implementation. Ideas for these features often emerge out of the system constraints that are a result of the system design, not necessarily a natural outcome of the problem domain. Differentiating between these two is probably one of the hardest things to do in any kind of design.

It’s vital to differentiate between these because IWBNI features seem especially prone to calcifying the current implementation. Back to our web services example, let’s say we implement this usage report, which dumps a text file every hour of usage statistics. We love that feature so much that we hook it up to our automated monitoring system as it seems like a nice way to monitor the “heartbeat” of the system. However, down the road we discover that we need a maintenance window that makes the file unavailable for a period of time that causes the monitoring system to alert us. Now we have a choice: we can patch up the monitoring to manage this exception, or we can re-think just how important the text-file interface is.

In this case I would argue that the text-file dump might instead be replaced with a simple web-request. When the system is in its maintenance mode, it could still answer questions about general availability (which is what we were originally interested in) without tying a more specific feature, usage, to monitoring. I don’t think that making the monitoring script more sophisticated is the right answer. More complexity there means a higher likelihood of breaking and it spreads some very implementation-specific details to other parts of the system.

The features and attributes of a system can be viewed like walls in a house. Some are load-bearing and some are not. The load-bearing features are those that without which, the house would simply fall. In your applications these are features that are the very essence of the software. An application like Quicken has an awful lot of walls. The load-bearing features of Quicken are the ledgers and reconciliation process. Without these, the other features of Quicken are irrelevant.

However features like downloading transactions over the internet or viewing pie-charts are mostly decorative. This doesn’t mean they are without worth, but they are not as essential as the load-bearing features. These could be removed and Quicken’s essence would still be preserved. Quicken is certainly more useful with these features, but those aren’t the features that generally drive users to use it. (NB: This is not to say Quicken is a well-designed application. But I’ll save that for another post…)

You can move the decorative walls around to change the space of a room without major fuss. Moving a load-bearing wall is a fairly major operation and has a huge impact on the character of the house and requires extra planning so that the house doesn’t collapse during the change. The danger of IWBNI is that it’s easy to confuse these features with essential “load-bearing” ones. Worse yet, the compound of multiple IWBNI features can end up as a load-bearing walls that are difficult to move. Revisiting our web services example, if more features like the text file were piled on and external parties began to rely on these, it would become much more difficult to move these in the future. It’s not difficult to imagine getting to a point where the original role of the web service is obscured by all of the other tangential bells and whistles.

Sometimes IWBNI features are user- or domain-driven. These seem like they might have a better chance of withstanding the litmus test. More often than not these ideas end up obscuring the core of the application, but these can be, relatively, easy to test with tools like mockups, user interviews and usability testing. In supporting services it’s much harder to evaluate these features. How do we do usability testing for a web service? Does the variable for a request belong in the path or as a query parameter? How do we figure out what consumers want? This is tricky because in this case we’re designing something by geeks, for geeks. This doesn’t mean that it’s okay to pile on a bunch of implementation details and stop thinking about separating our load-bearing features from our decorative ones. But it does mean that we have to be extra vigilant about the IWBNI features and view them with a particularly suspicious eye.

So I think this is the real trick–whether you are a visual designer, information architect or software developer–is to separate the essential from the decorative. Being able to sort features in this way gives you a chance to properly evaluate the cost/benefit tradeoffs. Without this I believe it is much more difficult to clearly see the value of a feature and its overall impact on the system.

So let me offer up a challenge: treat IWBNI as a codeword for something requiring exceptional scrutiny. When something is proposed as a IWBNI feature, regard it with a suspicious eye. When you feel yourself proposing a IWBNI feature, think long and hard about whether or not it is really “nice” or whether it might “essential” or “superfluous”. And for goodness’ sake, don’t get hung up on your IWBNI features. If they’re “nice” they probably aren’t a core feature anyway. You’re a smart, creative person and you’ll have other ideas in the future.

And finally, let’s remember the most common trait that nearly all IWBNI features share…

YAGNI*

* Ya ain’t gonna need it

You like command-line parsing, but you hate all of the bloat. Why should you have to create a Hash, then create a parser, fill the Hash out then throw the parser away (unless you want to print out a usage message) and deal with a Hash? Why, for Pete’s sake, should the parser and the parsed values be handled by two different objects?

Changes:

0.0.5 / 2008-06-12

• Removed sample_parser from bin (technomancy)
• fix a stupid bug causing an infinite loop for empty ARGV (technomancy)
• http://clip.rubyforge.org

Well, okay maybe that title is a bit misleading. I mean, we’re not talking about a transition from when dinosaurs ruled the earth to the Ice Age or the introduction of the combustible engine. But today I shut down my remaining home Linux server which ran this blog since its inception.

After overcoming a few technical hurdles I got this blog moved over to Dreamhost. Things seem to be running well, but if you notice anything, let me know.

It sort of felt like the end of “T2″ when Arnie willingly destroys himself in the forgery and signals a final thumbs-up before incineration. It was definitely time for that box to shutdown, but just a tiny bit sad just the same.

You like command-line parsing, but you hate all of the bloat. Why
should you have to create a Hash, then create a parser, fill the Hash
out then throw the parser away (unless you want to print out a usage
message) and deal with a Hash? Why, for Pete’s sake, should the parser
and the parsed values be handled by two different objects?

Changes:

=== 0.0.4 / 2008-06-06

* Fixed typo in error message (thanks francois!)

=== 0.0.3 / 2008-06-05

* Merged technomancy’s patches for simple 1 LOC parsing -> hash