Outliers

Since reading Blink: The Power of Thinking without Thinking and The Tipping Point: How Little Things Can Make a Big Difference, I’ve been looking forward to Malcolm Gladwell‘s next book. Outliers: The Story of Success didn’t disappoint, and I recommend reading it yourself.

As the book’s title suggests, Gladwell’s text is about success and outliers; however, he engages the reader from the get-go by starting with a definition of outlier expressly to follow-up by quickly suggesting a concrete redefinition of what is truly an outlier and what determines success. Gladwell challenges the reader to think in less-conventional terms (e.g. thinking about health in terms of community–beyond just the individual): “…there is something profoundly wrong with the way we make sense of success.”

Outliers has two parts, focused on opportunity and legacy, respectively. Part one emphasizes “from-ness” (i.e. from where (e.g. birthplace), from when (e.g. time, era, norms), from how (e.g. culture, legacy), etc.). In doing so, part one indicates by one example after another why merely personal explanations of success don’t work.

     Where are you from?

Do you see the consequences of the way we have chosen to think about success? Because we so profoundly personalize success, we miss opportunities to lift others onto the top rung. We make rules that frustrate achievement We prematurely write off people as failures. We are too much in awe of the those who succeed and far too dismissive of those who fail. And, most of all, we become much too passive. We overlook just how large a role we all play–and by ‘we’ I mean society–in determining who makes it and who doesn’t.

Gladwell states, “Achievement is talent plus preparation.” He then goes on to uncover patterns of achievement and underachievement as well as patterns of encouragement and discouragement. He focuses on the work ethic of those who are purposeful, single-minded, intentional–who achieve success by working much, much harder.

  • Adversity presenting itself as opportunity
  • Developing skills amidst obscurity
  • Meaningful – complexity, autonomy and a relationship between effort and reward in doing creative work
  • “Hard work is a prison sentence only if it does not have meaning.”

For example, the “10,000 hour rule” is discussed (i.e. its typically takes 10K hours of deliberate practice to develop true expertise and world-class mastery). The point of the discussion is not to admire those who earn such mastery as much as it is to understand the kinds of obstacles most of us encounter in the pursuit of such commitment. Furthermore, it concerns the creation of (more) equal opportunities for practicing in order to reach greater common potential: “Practice isn’t the thing you do once you’re good. It’s the thing you do that makes you good.”

     Are you regularly practicing what your core profession requires
     (e.g. modeling, design, coding, testing, writing)?

“Success arises out of a steady accumulation of advantages.”
“Extraordinary achievement is less about talent than it is about opportunity.”
     Talent: intellect, “general intelligence,” innate ability
     Opportunity: imagination, savvy, “practical intelligence,” surrounding
     community, family background, demographics, virtues and values
     (e.g. frugality, initiative, sacrifice)

“General intelligence” and “practical intelligence” are orthogonal (i.e. presence of one doesn’t imply the presence of the other); therefore, keep clear and separate (i.e. don’t confuse one for the other).

Part two, moves from opportunity to legacy and starts by focusing on cultural legacies (e.g. a culture of honor, where reputation is of foremost concern). The focus becomes about teamwork and communication (e.g. “mitigated speech”). For example, understanding cultural legacy as a way to effectively combat mitigation (i.e. developing clearer and more assertive communication where both transmitter and receiver are not a afraid to speak up or to speak straight).

To bring cultural legacy into better focus, Gladwell leverages the Cultural Dimensions work of Geert Hofstede (e.g. IDV – Individualism (i.e. what Gladwell refers to as the individualism-collectivism scale), UAI – Uncertainty Avoidance Index, PDI – Power Distance Index). For example, the United States has the highest IDV score and the fifth-lowest PDI score.

Mitigated speech and high PDI influence communication, especially when the person speaking (transmitter) and the person listening (receiver) have different orientation. In Western cultures, communication tends to be transmitter-oriented (i.e. speaker is responsible to communicate ideas clearly and unambiguously). However, in Asian cultures, communication tends to be receiver-oriented (i.e. listener is responsible to make sense of what is being said). For this reason, I believe that communication is both my responsibility and also a two-way discipline (i.e. if you don’t understand something speak up–I’m trying my best to be clear). It’s why I prefer more interactive sessions at conferences, etc.

As a mathematician by training, I was fascinated to learn that, as human beings, we store digits in a memory loop that runs for about two seconds. When you compare the fairly transparent Asian number system with the highly irregular number system in English, it starts to become clearer how English-speaking (English-thinking) student accumulate a disadvantage. Stowe Boyd goes into more detail of Gladwell’s treatment of this cultural legacy. (I need to start thinking si instead of four, qi instead of seven, etc. :-) )

Cultural legacy suggests to me that it would be naive to apply an American timeline to the future development of, for example, China. Rice paddies aren’t fields of corn or wheat (i.e. skill-oriented versus mechanically-oriented farming tradition). So why should it take the Chinese the same amount of time to “modernize” as it did take Americans?

You’ve likely heard or seen the business cliché “Your attitude determines your altitude.” Well, Outliers posits that success is not much about ability as it is about attitude. That is, success is a function of persistence, doggedness and willingness to work hard. Success is more about out-learning than it is about being smarter. School works, but there just isn’t enough of it (e.g. 180 days versus 243 days–American versus Japanese school year). Or said another way, school isn’t the problem as much as summer vacation may be.

In closing:

  • “Outliers are those who have been given opportunities–and who have had the strength and presence of mind to seize them.”
  • Success is a gift.
  • “To build a better world we need to replace the patchwork of lucky breaks and arbitrary advantages that today determine success–the fortunate birth date and the happy accidents of history–with a society that provides opportunities for all.”

P.S. I recently began a major revision of my Books page. You can now more easily see other book reviews I’ve posted herein. Soon you’ll be able to see what else is in my book library (i.e. just the business-related or software-related non-fiction therein). Why? Well, if you’re nearby and you see something of interest, please ask to borrow books of interest. If you’re not (i.e. regardless of your location to me), I’m hoping that opening up my library will help to solicit feedback as to what the especially good reads are (and why). I typically have multiple books queued up to read; so, knowing what should be top-of-list from my readers would be welcome feedback. Cheers…

Update 12/26/2008: Today I was able to get to watching the second part of Charlie Rose’s show on performance where, after interviewing Malcolm Gladwell in the first half, he interviewed the author of Talent Is Overrated: What Really Separates World-Class Performers from Everybody Else, Geoff Colvin. Mr. Colvin referenced the little known body of scientific work concerning deliberate practice, much like Mr. Gladwell drew upon it in Outliers. I appreciated Mr. Colvin’s belief, based on conversation with this scientific community, that the research frontier here is parenting.

Omea is open to the community

Now that Michael has publicly posted the official news in the Confluence wiki for Omea and in the newsgroups (i.e. coyly here via a three-part post featuring Esperanto and Alice in Wonderland), I want to also draw attention to this important open source event: http://svn.jetbrains.org/omeaopen.

I caught word of this milestone coming via Jeff Loftus. Serge was kind enough to cut Jeff and I in a couple of days early on the SVN link via the Omea multi-user chat room. (Using Miranda to access the MUC was painless).

I see, too, that David and Dmitry have picked up the news.

It took almost ten months since I posted my open letter to the Omea crew, but they have delivered.

Looks like I need to demonstrate “Omea Master” status. :-)

Spell checking Java source code

If your engineering team is like mine, it’s geographically distributed. Chances are that English is not everyone’s first language either. (To be clear, if you compare my Russian, Chinese or Indian to “their” English, I’m the one that comes up short!) So, I’ve been trying to determine an automated way to spell check Java-based source code artifacts.

Recently I found a set of open source tools that, when cobbled together, get me close to an ideal result. The answer began with finding a Google Code project called bSpell, which in turn brought in the following supporting cast:

  • Ant (build automation) – version 1.7 or later for formalized library (antlib) support
  • Checkstyle (coding standard adherence analysis)
  • Cobertura (code coverage analysis)
  • fant (Ant + Maven‘ishness)
  • JUnit (unit testing)
  • PMD (static rules analysis)

While Ant and JUnit are like old friends, it was nice to put “faces with names” for these other new acquaintances. For example, FxCop is a staple in my .NET-oriented development for best practice and coding standard rule checking; now I can experiment with the likes of Checkstyle and PMD to (hopefully) get similar results in Java.

To build bSpell, you first have to build fant. To build fant, you need to have Cobertura and PMD installed as Ant “extensions” (i.e. under an “extensions” sub-folder of %ANT_HOME% ${user.home}/.ant). You may want to upgrade the versions of JUnit and Checkstyle packaged with fant, too. You may also have to update other dependency versions referenced in build scripts (e.g. <fant-root>\etc\ant-inc\common.xml’s reference to PMD). A successful build of fant will result in <fant-root>\build\dist\fant-0.1.jar. A successful build of bSpell will result in <bSpell-root>\build\dist\bspell-0.1.jar.

To install bSpell et al into your Ant environment–where Cobertura and PMD are also installed under %ANT_HOME%\ ${user.home}/.ant/extensions–you need to copy your bSpell, fant, JUnit, and Checkstyle JAR files into %ANT_HOME%\lib ${user.home}/.ant/lib.

To incorporate bSpell into your Ant-based build process, create a new target in the appropriate XML build script. I called mine “spellcheck”:

<target name=”spellcheck” description=”Check DFS for proper spelling”>
   <taskdef name=”bspell” classname=”com.google.bspell.ant.BSpellTask” />  
   <bspell>
      <spellconfiguration
         spellCheckConfig=”${basedir}/project-bspell.config
         format=”console”
         dictionary=”${basedir}/english.jar
         reservedDict=”${basedir}/project-bspell.reserved
         registry=”${basedir}/project-bspell.registry“/>
      <!–Spell check the project (e.g. Java, properties, XML, XSD, WSDL, HTML and text content).–>
      <fileset dir=”${basedir}/**” includes=”**/*.*”/>
      …
   </bspell>
</target>

The first thing to note is an incorrect element name is referenced in the example bspell task call in the bSpell home page–it should read spellconfiguration as above, not configuration .

Next, note that there are four file-based inputs to the bspell task as follows:

  • project-bspell.config – I simply copied <bspell-root>\etc\spellCheck.config, renamed it within my project, and left its contents untouched. There are a number of settings herein; however, there isn’t any documentation to speak out; so, you have to scour bSpell source code to understand valid ranges and the effects of change.
  • english.jar – I simply copied this JAR file from <bspell-root>\etc into my project area as-is to improve project tool source control. Presumably there are non-English dictionaries that can be applied, too; however, I didn’t go looking for them since my needs are English-based.
  • project-bspell.reserved – bSpell will use this file to instruct its spell checker to ignore certain words. The baseline file I used, %ANT_HOME%\etc\fant\bspell\reserved.dict, contained two sets of words: one associated with “general” and another associated with “java.” I ended up leaving the Java word list as-is and simply added words to the general list. Given that I didn’t modify my bSpell configuration file (e.g. IGNORE_MIXED_CASE=true and IGNORE_UPPER_CASE=false), I had to specify all-lowercase and all-uppercase values for  acronyms to be ignored. Given the lack of documentation on, for example, the effect of a word addition to the general list versus the Java list, or the ability (or not) to create additional, named word lists, it may be worth scouring the bSpell sources for details.
  • project-bspell.registry – bSpell will use the file’s extension to detect which parser should be used. In case of .java, it will load the JavaParser to parse the Java source code (i.e. com.google.bspell.parsers.JavaParser.class within bspell-0.1.jar). Out-of-the-box, bSpell provides one other parser: TxtParser. You associate parsers with file extensions in the registry file. I associated com.google.bspell.parsers.TxtParser with txt, properties, xml, xsd, wsdl, and html. If you specify a file type in your bspell task file sets that isn’t listed in your registry or recognized by default in bSpell (i.e. .java), bSpell throw a java.lang.RuntimeException.

A run of “ant spellcheck” from the command line produced a spell check analysis of over 600 files in under two minutes on an average workstation. So, I can now spell check my Java projects in the time it takes me to grab a fresh soda from the office refrigerator. Nice!

So, what’s missing?

  • Well, for starters, bSpell (and fant) are only at version 0.1 (as numerically determined by their committers). Nevertheless, it would be useful to have a ready-to-deploy package for bSpell rather than have to go through a reasonably involved build-then-deploy process, as noted above.
  • bSpell needs documentation–not just Javadoc, but user guide style content (e.g. explaining bSpell configuration file values and how they alter tool behavior). There is a bSpell wiki, but it is empty at the time of this post.
  • bSpell needs more built-in parsers. While associating com.google.bspell.parsers.TxtParser with txt and properties works, associating TxtParser with xml, xsd, wsdl, and html, leads to extra work in reserved dictionary definition. That’s because TxtParser isn’t designed to ignore language keywords and other common-but-not-true-English constructs in such document types.

Thanks to James Mao & Co. for bSpell. (I see that James and Glen are both committers on Apache CXF, too.) Keep up the good work, guys!

Update 10/8/2007: A colleague of mine kindly reminded me that modifying the actual Ant distribution is the “old” way of doing things, and was replaced by the .lib directory several Ant releases ago. So, I tried to correct my post above to reflect a more appropriate way to achieve the same results. Thanks, Martin.

An open letter to Jetbrains about Omea

From: Craig Randall
Sent: 5/30/2007 7:45:19 PM
Newsgroups: jetbrains.omniamea.eap, jetbrains.omea.reader, jetbrains.omea.pro, jetbrains.omea.dev
Subject: When will the source finally become open for Omea?

Omea Team-

Many months ago Jetbrains announced that Omea was going open source. However, to date the source is still entirely closed. There has been very little explanation about the lack of follow-through (timely or otherwise) concerning progress (or challenges) in achieving the publicly announced goal of making Omea an open source project.

When you read through a significant number of posts since the Omea announcement, it’s obvious that the Omea community is loyal. But all loyalty has its limits, and I fear that Jetbrains is pushing this community to the point of writing off the announcement as vaporous. That is really unfortunate and completely unnecessary. From my correspondence separately with you, I know that there is still passion around Omea (i.e. the core dev’s at Jetbrains).

So, what say you? Can you give your long-suffering community a definitive answer about when you will finally make Omea fully open source?

-Craig

It’s also been almost six months since version 2.2 was released. So regardless of the critical environment around open sourcing your product, you need to convince your community that, regardless of open/closed, Omea is alive and well, receiving its due care and feeding one way or another.

You made Omea free (as in free beer); now, please liberate Omea.

Sincerely, your languishing advocate…

Update 3/14/2008: JetBrains has finally released Omea under GPL v2, and the community can participate in its ongoing development (!!). More in a separate post

Open source Omea!

Earlier today JetBrains Omea Development Lead, Michael Gerasimov, made it public and official: “After collecting your opinions and having long internal discussions, we have finally decided to move both Omea Reader and Omea Pro into the open source domain.” Michael had alerted me to this excellent news privately before the newsgroup-based announcement, but once again I agreed to wait for JetBrain’s lead.

This is great news for Omea users like me, content management developers and solutions architects like me, and fans of open source… :-)

Here are some more details from this announcement:

  • The licensing of this new open source project has yet to be announced (e.g. GNU, Apache, etc.).
  • The repository for this project has yet to be announced (e.g. SourceForge, etc.).
  • Omea Pro is immediately available free of charge.
  • JetBrains will release version 2.2 of Omea Pro and Omea Reader before the product goes open source in the traditional sense.
  • JetBrains is going to ensure Visual Studio 2005 readiness before the product goes open source (e.g. project files, potential optimization for .NET 2.0, etc.).
  • Source code currently resides in a p4 repository. It will migrate into a Subversion repository before it goes open source.
  • The new build scheme will leverage JetBrains TeamCity.

Alas and unfortunately, omea.org is already claimed by Ottawa Musicians and Entertainers Association.

Update 3/15/2008: Although over a year later, Omea is finally open to the community In doing so, JetBrains has released the open source project via SVN off its domain and with a code base requiring .NET 3.0 and Visual Studio 2008–among other components.