In Defence of Pokemon

Often, I hear parents complain about Pokemon. For those who do not know what they are, I am talking here about the fantasy world where humans and creatures called Pokemon coexist. The Pokemon can be domesticated and trained for battles by Human trainers. Pokemon are all strange looking creatures, often resembling some kind of animal and with a name that is almost always a mangling of some real words with makeup words, resulting in gibberish to the uninitiated.

I think these parents are misguided and are themselves turning into a curmudgeoning generation that mistakenly bemoans the lack of taste/ethos/skills in the young ones. Rings a bell? It should, since it is a recurring theme.

But to the point. The movies may not be your cup of tea, but most of the major literary themes can be found in there -- love, ambition, jealously, rivalry, sacrifice, courage, perseverance, duty etc. The Pokemon world is coherent enough to suck in the watcher and appeal to kids. The one movie that for me signifies this quite clearly is Lucario and the History of Mew, where Truth, Friendship, Sacrifice and Duty feature strongly. Please forgive your children for not watching De Avonden (talk about boring), but do not accuse them of having no taste.

Then there is the computer game on the Nintendo DS. In game terms it is a grind, full of micro-rewards, a very effective way to draw people into games. What I see in my own kids is that they learn to cope with setbacks, think about ways to succeed and persevere through it. The game is in english and they try very hard to understand the words, even picking up a number of them. I am amazed at how much they can already understand of the text. Besides the solo version, the game offers easy ways for groups of kids to hook up and play/trade/fight/chat together. Calling it anti-social just becase the means for conducting social traffic is not well understood is not doing it justice.

Finally, there is the trading card game. This strongly stirs the collecting fever that seems to be part of our genetic heritage. The cards of the game come in four varieties: common, uncommon, rare and ultra-rare. A tried & tested tier system that was first introduced by Magic the Gathering. I am surprised to see how easy markets are formed ad hoc and anywhere by groups of kids with their books, boxes and single cards stuffed in pockets. They deal easily and smoothly. Yes, there are some negatives, for example stealing and ripping off smaller kids, but more importantly, I see my own kids building up stamina, tolerance for trading away their own property, empathy for what the other kid wants (Theory of Mind anyone?) and developing savvy in what constitutes a good deal.

The last reason why I think Pokemon is not bad is deeply personal. My youngest son is suffering from Selective Mutism, which is often misunderstood by people to be shyness. It's hard to explain the affliction, but it is probably best described as a persistent, strongly rooted refusal to speak in certain situations with certain people. The affliction is curable by therapy and one way for kids to overcome Selective Mutism is, in clinical terms, if the price of persistant silence is higher than the social cost. Ever since my son has been engaged in trading Pokemon cards, he often found the cost of maintaining silence too high, and sometimes breaks that silence to fuel his trades. This blends in nicely with his therapy and has every appearance to speed up the process considerably. You can imagine that for this fact alone, the Pokemon movement has my undying gratitude.

Money for Nothing

Some 375 years ago, the Netherlands (then the United Provinces) just recovered from a bout of intensive fighting with the Spaniards. It had a lively trade, resulting in the Golden Era. This boosted the cash income for the upper class so much, that it desperately sought outlets, burning in the pockets of rich people. My fellow countrymen therefore developed an appetite for the beauty of the tulip; a rare item in limited supply. The insatiable appetite for exotic varieties turned into the first real economic bubble, as middle class speculators joined the fray and short selling (ie, gambling on price increases with borrowed money, effectively incurring double risk) was introduced. The history of this mania is described eloquently in the book Tulipomania.

The appeal of easy money has always been big. It is what any casino thrives on, and what makes Pyramid Schemes so successful in preying on the naive and gullible. Ratio is thrown out of the window in pursuit of the big fish and the fact that so many people join in only reinforces the herd mind that the mass is on to something.

Some of the appeals to people's lust for easy money is cleverly guised, such as The 4-Hour Workweek describes. And appeal it does -- how could it not? Gaining big money while doing (almost) nothing is so enticing, so seducing that it triggers the same mental area as it does when participating in bubbles, lotteries, casino games and pyramid schemes.

The author of The 4-Hour Workweek is obviously a gifted person -- and well aware of this fact given how he flaunts his accomplishments! -- which is a hurdle, inhibiting mass adoption of what is described in the book. To be system beater like the author is, is a rare gift. The author goes forth to describe how he delegates work to others in such a way that he gets relieved of all toil, except a couple of hours to keep things moving.

The 4-Hour Workweek is a bit more subtle in its negative effects however, when compared to the afore-mentioned economic phenonema, and it is all about added value. What the author works on is a mix of differences in price (the same argument used for outsourcing), his own considerable insights, available talent abroad and a non-transparant market. As opposed to outsourcing, which requires lots of actual work, experience and management to succeed with, the author adds no further value to the process, so builds up no competitive advantage whatsoever.

Let us just fantasize for a moment that Timothy Ferris' approach is broadly adopted. We have all these entrepeneurs, managers and experts whose sole aim is to minimize their working hours as soon as possible. What added value does that person build? What added value does the company build? What added value does society as a whole build? You can delegate your work away as much as you like, but there is always a downside to every upside. In this case, the downside is the loss of skills and experience and henceforth any competitive advantage that may have been wielded. A downside that is felt all the more if well-packaged parasitism becomes the norm. Just ask yourself how easy it could be for the delegatee to run away with your business.

Structural shortcuts to success are only for a few lucky or brave souls, and are by their very nature not intended for the masses. Contrary to popular belief, the best way to achieve your goal is still to identify it, set the parameters and work hard to make it happen. Like Erasmus said, Qui vitat molam, vitat farinam, or He who runs away from the mill runs away from the meal. In short: No pain, no gain.

The Black Art of SEO

I have been dabbling in the superstitious side of IT recently; Search Engine Optimization, or SEO for short.

Google guards it search engine secret jealously so know one knows for sure what is hot and what is not. Like any half-decent government organization that desires a certain behaviour from its citizens, it is glad to tell people how they should behave, but refrains from telling the exact way in which the appraisal takes place. Better to let people act in the spirit of an idea, than to give them the exact parameters and inner workings, which tends to provoke abuse.

On the downside, and for this reason, the SEO market looks a lot like the paranormal community -- no one knows for sure what is happening, so anyone can claim to have divined The Algorithm (tm). Proof is sketchy and scientific evidence hard to come by, more so if the search engine's crawlers take some time to revisit your website, leaving a big gap between a change and its effect. What seems to be sure is that Google has succeeded in striking fear into the hearts of SEO experts. Ever since it degraded the ranking of sites meddling with link farms, people seem to be watching their steps more carefully, aiming to please, not to anger. What more could the Great G ask for?

Having said that, SEO has its own scale of near-certain knows to urban legends. On the near-certain side are the HTML tags on a page which are important for Google to determine what a page is about. Keywords with a higher importance are taken from the following tags:

• URL; give your pages names which are meaningful in relation to the content


• title; it is advised to stick the important keywords to the start of the sentence


• h1/h2/h3; in order of importance


• bold/strong; emphasis might denote importance of keyword


• image; the name of the file and especially the alt text


• link; the title of the link and the anchor text

As I am naturally disinclined to human-crawl a website looking for these tags, I hacked together a Java program based on HtmlUnit (my latest love!) that does the job for me. I give it a URL and it parses the site, following all links to pages on the same site. Of every page it checks the important HTML elements. The outcome is a report where you can see what keywords are being picked up by a crawler. It does not do SEO for you, but it certainly helps if you do not see the keywords that you would have expected in there.

If you want the app (disclaimer: no unit tests, all-round error checking, build etc in place), are interested in a report for your site or can add valuable SEO divining capacities to the tool, please drop me a line.

Why Gems is mere carbon and Maven is a schmuck

The first time you run Ruby gems to install components, you have to admit it all looks pretty slick. The application is set up and the developer goes to work, adds a gem here and there

Then the downside becomes painfully obvious.

All the components that were installed by the developer have to be installed by each and every other developer who wants to work on the application.

All the components have to be installed on all the servers where the application is to be deployed.

Truly, I am not kidding.

So for every component added to the application you will have to run this gauntlet. Since component changes are in flux and need to be dealt with as such, instability is bound to result.

To add insult to injury, the concept out-of-the-box further imperils Ruby's Cloud-ability, because it requires root access to deploy gems. As long as this issue is not addressed, Ruby is bound to miss out on the movement.

The Ruby community soon enough saw the downsides of the gems approach, but as solutions go, the proposed practice is lamentable. Gems need to be unpacked (similar to extracting content from a ZIP file) and added to a subfolder in the product. Then the application will have to be customized so that it reads the gems' content as part of the project structure.

I am sure the Ruby community would have much preferred a cleaner solution like Java offers. Instead they chose the enticing route of setting up their own disruptive technology. Too bad the disruption was for the user, not for competing technologies.

The Java community will not be left off the hook, however, having introduced and hailed its own piece of well-intended, but flawed reasoning and I will gladly go against the grain to make my case.

Maven has the concept of a repository where dependencies can be stored (usually JAR files). Some reasons are given on the Maven website why those dependencies must not be stored as part of the project; takes too much room, impedes checkouts and does not require to be versioned.

Can you believe that those are actually the real reasons for Maven's repositories? You better believe it, because there is not much other value to the concept, even downsides.

For one, there is the downside of having a compile-time dependency on external sites for which I wager most organizations have no Service Level Agreement in place. Unacceptable to any serious company. Though there are ways to bypass the problem by setting up a local repository, most of the time that is overkill, introducing more complexity than the value you get out of the deal.

And let's not forget the extra hassle you get when setting up your development project. Normally I select the JARs in the library subfolder of a project and be done with. Not so with a Maven repository. You will actually have to go through the POM and harvest the dependencies one by one.

So here is Maven with its fancy repository, saving you disk storage and checkout time. Would you consider that a good trade-off for an extra layer of complexity and more hassle?

If you build your application, always internalize your dependencies whenever you can. You keep your teammates, your systems operator and yourself much happier this way.

Predictably Irrational

If you are a programmer, you are bound to see the world and its inhabitants a bit different than most people, more inquisitive, not exactly more rational, but definitely searching for those building blocks. I used to think that was a handicap you just had to cope with, especially in social traffic, since discounting the richness that Humanity itself brings to the fore is usually frowned upon. That is, until I read Predictably Irrational by Dan Ariely. The author demonstrates that Man's mind might be easier to program than a Java Enterprise application, something which I wager will be agreed upon by NLP students out there.

The books shows us that:
- Man is great at comparing things; things which are great but cannot be compared are doomed to fade away
- Man chooses that which is Free; even when a rational human being would choose a more sensible option
- Man anchors new things at a fixed value; the new thing is valued and will forever after gravitate around that value
- Man does not mix social and monetary currency; if something is done on a social basis, monetary compensation devalues it
- Man is beyond reason in heat; despite what people think of themselves, they go much, much further when in a state of arousal
- Man is a procrastinator; if something can be delayed, it will be and sometimes an authority to prod and stir is a good thing
- Man values that which he owns; it will be traded more expensively than its actual worth
- Man does not burn boats; bet hedging is deeply ingrained in our psyche, even when it is not beneficial to do so
- Man lets expectation determine reality; that which is expected as an outcome shapes the actual outcome, not only in the mind, but in the body as well
- Man values that which is expensive; for a certain thing bestowing an effect, its effect will be greater when it is more expensive

Being practical, I think the following would be valuable for a company to adopt:
- on offering a product, make sure a comparable (albeit inferior) product is offered -- if it is a competing product, include it as part of your message
- include something nice for free
- if you want your company to be social, align it so all the way (and forget about demoralizing and demeaning reorganizations -- good companies do not reorganize, they prune ALL the time)
- do not make your product too cheap (every Marketing student will tell you this anyway)
- make it easy for your boat not to be burned (eg, customers who leave can keep their data in your system for free)
- challenge each other vigorously (ban out the procrastinator in yourself!)

A good read, definitely worth spending some time on if you are interested in what makes you tick.

Ruby, the End of the Honeymoon

At the risk of being threatened, ostracized or even lynched by an angry mob, I am boldly stating here that the Ruby movement is past its heyday.

"Why?", you rightly ask.

The signs were there all along. It started with the usual pioneering enthousiasm that comes with a new technology, and admittedly, I joined in the choir. Ruby, or more accurately, Ruby on Rails, sure played its part in upsetting the existing order, especially in the field of webclient development. The copy-cats soon followed, with Grails being the most honest about where it borrowed its idea from.

For some time now, I have noticed that quality Ruby people are hard to come by. For some time too, I noticed, that a number of Ruby pioneers start to lose interest and drift to other promising languages such as Scala, or even back into the fold of Java.

Ruby on Rails applications are slow. I have had the luxury to have a Ruby crack in my team who knows how to tune these little beasts and crack that whip. Grails applications, on the other hand, are not slow. They run directly on the JVM. An enviable position, that Ruby believers can only glare at without offering a solid alternative.

Aha, I hear you say, that's where JRuby, Ironruby and the likes come in. Now I would like you to heed this -- we are talking here about hand-crafted Ruby interpreters that make sure Ruby can be run on the JVM. Tools that have their own issues (we had a huge concurrency problem with an older JRuby version) and introduce one extra element of complexity into the Technology stack. Everything that people think up in the Ruby interpreter needs to be faithfully duplicated in JRuby, but then written up in Java. DRY? Not really. The notoriously sloppy documentation and audit trail that unfortunately appears to be a convention in the Ruby community only adds to the task. I have great respect for these brave developers, but less faith to build essential software on such a platform. And don't even get me started on how JRuby-hosted Ruby code is its own island (yes, you can ferry between the islands, but you will get seasick), contrary to Groovy and Scala applications which interact freely with Java code.

Finally, the commoditization of hosting web applications, especially by Google, pushes the knife home. Google's cheap hosting offer only allows you to run on the JVM, effectively adding a premium to your service if you want to run full-fledged Ruby on your own servers.

Ruby and Rails have brought a lot of good to software development, but alas, their time in the limelight has come to an end.

A Tribute to the Bug Hunt

There are few experiences in software development quite as humbling and as satisfying both as the Bug Hunt. The search for an elusive problem that causes systems to crash, data to be lost and bits to be unwantingly inverted is a wild chase where one is peeling off several layers of proximate causes in order to get to the ultimate one.

The interesting aspect is how the Hunt is often opened by having a preconception of what the problem is and where it resides. Often a hunt ends there. The interesting ones are those where the preconceptions get shattered several times as they are revealed as mere proximate causes or worse, false leads.

The humbling part, for me, consists of how I sometimes have an idee fixe about what the cause is and how that assumption turns out to be untrue. I daresay that this aspect made me more conscious in my interactions with other people and prevent me from jumping to conclusions.

There are many out there who are happy to have found the proximate cause and stop there. The symptom is solved. For example, a warning light flickers in an irritating way, so take out that light. Symptom solution is in my experience also typical when an electrician comes to repair something in my house; they observe the symptom, declare that the cause and proceed to fix it. They don't ask that critical question: why does this light flicker?

It amazes me to see this is often the prevailing mood in software development as well. If you are in a position to question someone who has just solved a problem, ask them why the problem occured and keep on asking why until you have satisfyingly heard the ultimate cause. If this is not business-as-usual, I predict you will find the level of understanding to be lacking.

The lack of understanding will ultimately come back and bite you when your dirty-fixed applications will be plagued by problems that start cooperating in ways unimagined to cause serious mischief, multiple root causes making the hunt even harder. Your application is more likely to reach the end of its life prematurely.

The Bug Hunt consists of five parts:
- arrange a problem description
- reproduce the problem in a separate environment
- determine the root cause by isolating the problem
- propose a concept solution
- implement the fix

The only part that should be subjected to economical choice is the fourth one, ie the type of solution. Here you can choose a proper solution, a quick-fix or no solution at all as the situation allows. Do not save costs on the hunt itself! You will be sorry that you did.

The end result of the hunt should be a narrative that explains exactly what has happened. If you are using an issue tracking system, demand that the hunt is documented meticulously, so knowledge is shared and valuable information on the patient preserved.

Doing all this right, will keep knowledge about your application with your team on a high level and the application itself is kept in good shape. You are better positioned to scale up, address new problems, refactor old code and add new functionality. The Bug Hunters are the heroes of your team; honor them!

Remember, the most powerful weapon of the Bug Hunter is that one little word: why.

Good Hunting!