Case "Dynamic Order By" When?

The other day I ran into a nicety of SQL that I was not aware of. Not that that is special, but I think this nicely illustrates how the Old World has taken into account aspects which are not (yet) secured in the New World.

Let us suppose you have a table that has a column called state. Within that column you have the following distinct values:
- pending_approval
- approved
- rejected

Let us also assume that you want to order retrieved rows in the exact same order as I listed the items.

A regular order by won't do. It will show the results alphabetically, either ascending or descending.

Usually, I am inclined to prepend the values with sortable pieces of text such as 1_, however this messes up the semantics of the value. Doing this makes me feel dirty.

Well, what do you know, SQL actually took this scenario into account:

  select * from table
  order by case state
    when 'pending_approval' then 0
    when 'approved' then 1
    when 'rejected' then 2
  end;

What a gem!

The functionality goes quite deep, giving you even the option to fetch values from other columns.

Regrettably, this functionality cannot be accessed through JPA/Hibernate. My good colleague and database prima donna, Ron Smeets, advises to lay a view upon the table. Interesting idea, though for the specific use case I am looking at, this is not an option. This probably means going back to using JDBC.

As far as I am concerned, certainly goes to show that the database layer still holds treasures for application developers to discover.

Hiring people

If you are a manager and you are in a position to hire people, there is something you can do right really easy and really fast.

Do not be dismayed by people whom you think might be more talented than you yourself are!

Instead, relish the thought of hiring those people, even though the mere thought gives you shivers and breaches your comfort zone. You are now truly laying the foundations for a stronger organization.

In the end, you will be repaid with something much more valuable than a kingdom of mindless zombies, willingly assuming the position, nodding aye to everything you say and laughing to every stupid joke you make. Instead, you are in a position to experience being part of a team that can shape history.

Not only that, but there is no better way to keep you sharp and on-edge than surrounding yourself with those that are likewise equipped and honed.

So next time you are evaluating a candidate and you feel slightly threatened -- hire the person!

On Strategy

World War I is, bare none, the most tragic war fought the last thousand years. Some say the war started in the 1870's era and ended on the eve before World War II. From a technology and strategy point of view, this is true. Nothing quite boosts human mental prowess more than a deep and enduring crisis; the war started with outdated ideas and technology and ended with all the concepts that were used to wage the second tragedy in the same century.

Take, for example, the approach on the battlefield -- long lines of young men, trodding slowly towards their doom. And even those who arrived at the other end of No Man's Land could not hold on. There were no supplies, no backup, no mates to back up their positions. Seldom was terrain conquered for long. Reconquests of trenches bought dearly with the blood of many were the norm.

The British did not innovate their fundamental tactics. Their society at that time was highly stratified with little room for initiative in the lower strata. On the other hand, and contrary to popular belief, Germany was almost the inverse; it had a strong middle class. It invented a concept that nearly blew the Allies away -- Stormtroopers. Soldiers with decentralized decision making authority, often by non-commanding officers (NCOs in jargon, ie those below officer level). The tactics were aimed at deep penetrating units, circumventing tough defenses. New weapons were added to the arsenal; flamethrowers and grenades. The units had a high degree of self-coordination and self-reliance, without overbearing staff interference up to the level that they did not, and indeed, could not, know about. The unit was very successful and mostly due to incompetence of the over-hyped general Ludendorff (suffering from a nerve breakdown after his failed Peace Offensive), was the advantage thrown out of the window and could the Allies win the war.

Strategy permeates everything we do, even though we may not be conscious about it. It is about how we deal with everyday aspects. What do you do if someone treats you unkindly? Will you put up a fight? Offer friendship? Walk away? Strategies are most often not designed. Indeed, they evolve. You try something; doesn't work? Toss it out and try something else.

The best examples are those seen in nature. Think about the arms race between prey and predator, or how parasites and influenza viruses keep on adjusting to outrun what medicine can throw against it. The relentless pressure of evolution is the best evolver of new strategies.

Nor is strategy a single thing. It often consists of a number of characteristics that strengthen a generic theme; in companies, these could consist of culture, processes, skills, technology. The best companies in the world have strategies that work. If you break those down, you will find many, many parts that all interrelate and enforce each other. Do not even bother cherry-picking; it's bound to fail, because you do not have the overall strategy.

It makes me think. Can a really good strategy actually be designed? Can it come into existence without the pressure to change? Can it evolve into the target strategy withouth the cultural preconditions being in place?

I think pressure is essential. And so is the holistic view. Without pressure, no one will feel the need to change and without that energy nothing will happen. Without the holistic view, all the measures are shrapnel shots going nowhere. It needs to be part of a bigger picture, the parts reinforcing the whole.

As for evolution or design; strategy suffers from the same problem as software development. Everyone accept nowadays that the waterfall model of software development does not work and smart people invented the concept of iterative development, which for sure works a lot better. So it is with strategy. I firmly believe that it is not possible to design a 100% sound strategy upfront. You use your instincts and experience to aim as good as you can and then evolve the concept as you go.

Culture might well be the hardest one. How do you know you are not shooting for an impossible target? The Will to Succeed may well be blind to impossibilities. Do you have the right people on board? Are you yourself the right person to pull this through?

Personally, I stick to these rules:

• design and look at the big picture, see how it all interacts
  
• know what not to do and block that out
  
• relish a crisis; it offers the opportunity for change
  
• don't be too harsh on yourself for not seeing the entire picture (yet)
  
• be fair in appraising weaknesses
  
• learn from others, read biographies of successful people
  

Despite an intensive, lifelong fascination for anything that has to do with strategy, I still cannot claim to have mastered the subject, though I do claim to derive a lot of intellectual pleasure just thinking about it.

Geeh... migration

Last saturday we migrated two separate email domains and our Google Apps domain into one Google account. Besides the mailboxes, we therefore also had to set up Google Talk buddy lists, export/import the calendars and copy the Google documents.

We started by having a general reset on all passwords, so we could execute all phases easily.

The mailboxes went very smooth. Google has the right tooling to enable this. The only hiccup was the transformation from folders to Google's labels. Deeply nested folders come out really ugly, but hey, what can you expect? I prefer labels to folders, especially since folders do not cater for multiple annotations like labels do. And let's face it, like an animal that is both bird and fish, some mails refuse to be defined by a single label.

Google Talk is easy as well. There is a global setting which automatically makes domain users accept any buddy request -- this is key! After this setting is enabled, it is just a matter of copying the entire email list into the invitation text field for a user and the deed is done. Google could improve its service considerably by having a setting which automatically connects all domain users.

Calendar has the same ease of migration as Google Talk. Just export the calendar and reimport it, mapping to the right user names.

Google Docs is a bit of a pain. There is no way to change ownership of a document to someone outside of the domain (@Google -- improvement?). Luckily, the Google Docs API is splendid. I made a custom script that does the following:

• analyze all documents and flag those that are owned by a user
  
• check the access rights on that document
  
• download the document to a temporary location
  
• upload the document to the new Google Docs account
  
• reassign the access rights to the uploaded document (also using new email accounts)
  

The script performed well. Noteworthy is that on uploading a document in an automated way, a lot of garbage is created by Google. I think it has something to do with uploading a high number of documents in quick succession. Anyway, the script also cleaned up the Google garbage, which was not hard since the garbage documents still had the original filename used for downloading.

After the fact, I noticed I forgot about document labels and email notifications when a document changes. Not a big deal for people, but if you want to be all-inclusive, you should have this as well.

The migration took less than a working day with a minimum number of complaints.

Here's to Google!

How the Mighty Fall

Jim Collins, author of Good to Great, is back with another book. Whereas Good to Great focused on what makes companies stand out, How the Mighty Fall inverts the equation by looking at the prime reasons for companies not making it.

The author tries to apply the same sound formula; i) gather a lot of scientific data, ii) discern the patterns, iii) write a good book about it.

Oh, how Jim Collins must have bewailed his fate when he found out there are many, many more ways to fail than to make it.

Good to Great comes back with solid and applicable advice. This made the book an instant hit among the target audience. And rightly so.

How the Mighty Fall's main contribution to understanding failure is the 5-phased lifecycle of a company:

• Hubris born of success; the company grows and starts to adopt an arrogance stance ("We won, because we are better")
  
• Undisciplined pursuit of more; growth becomes the mainstay and strategy (in business mainly the art of not doing something) is thrown out of the window
  
• Denial of risk and peril; warning indicators of imminent doom are ignored
  
• Grasping for salvation; doom is upon the company and anything which might reverse the situation is tried
  
• Capitulation to irrelevance or death; the company is sold or goes bankrupt
  

In other words, a very generic way of describing failure, which has mainly to do with character and culture. Given that there are so many ways to fail, the author falls back on safe ground by invoking Good to Great lessons. The one addition he makes is what you can read from any biography of a great person, like Lincoln or Churchill -- never give up, never give in.

If you are new to Jim Collins' works, skip this one and honor him by starting with Good to Great instead.

Why Maven is a Schmuck (part II)

This evening I had an excellent dinner with my friends Anthony and Erik, both of whom I hold in high esteem. There is nothing like a full-blown argument in good company and while we broached several topics, the one most noteworthy was that of Maven.

Anthony opened his broadside fire by claiming that a lot of the problems he saw in projects nowadays were Maven-related. I couldn't believe what I heard: a kindred spirit with sharp criticism on the untouchable Maven!

Maven adds considerable complexity by adding a layer of abstraction, obfuscating a lot of the dependency magic. Developers like Erik have no problem grasping the whole playing field, but the impact of this complexity on the team must not be underestimated. After all, team members must be facilitated by the tools, not obstructed or forced to learn more than they need to know, which in a way is what Maven imposes.

Anthony went so far as to claim that for large projects a dedicated Maven expert is required. I feel a lot of sympathy for that claim.

We concluded on the following regarding Maven's upsides:

• IDE support; it has solid support in setting up project structures -- think Eclipse and IDEA plugins which generate from the POM. With the right POM, you are up and running literally in minutes
  
• Reports; the built-in support of Maven for many types of reports is way more advanced than what its peers offer
  
• Intermediate product support; any project which produces intermediate JARs to be reused by other projects is bound to be a dependency nightmare, but Maven takes care of that mess best. Question is: aren't these the niche projects?
  

One thing we dealt with resolutely was the convention to split up a project in many sub-projects. A sub-project which does not result in its own deployable, nor is about to be reused in any way, does not deserve its own sub-project. The argument that future architecture splits are thus enabled is an academic train of thought which is rarely exercised in real life, though imposes heavy costs throughout the life cycle of the project. Keep it simple. Most projects belong in just one project folder.

At the end of the argument, both Anthony and I were more in favor of internalization of the dependencies (see my other article on Maven), while Erik remained firmly on the side of Maven dependency management.

For internalization, there is a price to pay though: internalization means that one developer goes through the pain of "getting it right", but after that it works for all other team members and for deployment to the target environments.

Excellent discussion of which I hope to see a lot more in the future.

The 5 Temptations of a CEO

The other day, Erik pushed a little book into my hand, called The 5 Temptations of a CEO.

The book is written in what is called the business fable style. Ie, storytelling as a way of teaching. More correctly, I would term it a parable, but I think the inventors of the term business fable wanted to steer clear of that one for its religious connotations.

The book follows the soul searching of the protagonist, a failing CEO, who not so much reverses his course, as identifies what the reasons for his failing are.

The author goes forth to summarize these failing under appealing titles:

• Status over Results; when personal agendas, career paths and status symbols prevail over what the company requires to subsist. Suddenly there is a lot of "I" in the team.
  
• Popularity over Accountability; when personal ties are more important than keeping people to their promises, thus holding them accountable. People slacken off and don't take their responsibilities serious anymore. Complacency sets in. This one also has to do with using your reports as allies and venting ground.
  
• Certainty over Clarity; the need for ever more information and procrastrination by a decision maker before making the call. In board game terms, I would call this Analysis Paralysis.
  
• Harmony over Conflict; if people refuse to slug their arguments out to prevent others from getting flushed, there will be a lot of suboptimal decisions. Those who can work the dynamic best by emotionally blackmailing the group hold sway
  
• Invulnerability over Trust; working to be one-up will push others to raise their defences as well. Any argument will now become one of status and survival, immediately tied to personal interests.
  

The text behind the headers is my own interpretation, which will show you that I concur with the author in his conclusions. Powerful stuff for anyone in a leadership position to consider.