Friday, December 31, 2010

Five Books That I Enjoyed Reading in 2010

The followings were the five books that I enjoyed reading most in 2010:

  1. Dreams From My Father by Barack Obama

  2. The Black Swan: The Impact of the Highly Improbable by Nassim Nicholas Taleb

  3. The Girl with the Dragon Tattoo by Stieg Larsson

  4. 3:59.04:  The Global Quest to Break the 4 Minute Mile by John Bryant.   

  5. The Best Australian Essays 2010 edited by Robert Drewe


Special mention goes to Pride and Prejudice by Jane Austen. It happened to be the first book that I read in EPUB format on a mobile device.

Thursday, December 30, 2010

The Banyan Tree of Limbus

On Christmas Day, a couple of Limbu friends favored us with a visit to our place at Kogarah, and, over orange juice and canapes, we discussed the consanguinity taboos that govern Limbu marriages.  My friend's spouse pointed out that if the consanguinity taboos were observed strictly, a Limbu lad or lash would find it difficult to find a suitable match.

The Limbu marriage code forbids two types of marriages on consanguinity grounds. First, marriages between parties having same surnames are proscribed in most cases. I said "most cases". For example, my mother's Limbu surname is "Menyangbo", and, as far as I know, a Menyangbo cannot wed another Menyangbo.

My own Limbu surname is "Thebe". Thebes are further sub-divided into "Thupukko", "Sing" and "Maabo". A union between a Thupukko Thebe such as myself and a Sing Thebe is legitimate but not, as far as I know, between other Thebe sub-types. This inconsistency betrays the somewhat arbitrary, malleable nature of this particular taboo, and may suggest that Sing Thebes were once a distinct clan who were assimilated by the numerically superior Thebes at some point in history.

Local legend has this to say about the origins of Sing Thebes: The first Sing Thebe was a Thupukko Thebe who went foraging for firewood in the forest and got lost. So, he became Sing or "Firewood" Thebe. This legend is a warning to any future Sing Thebe genealogist tempted to find false glory by tracing their roots to the "Singhs" of North India. Bull dust such as  "Sing Thebes descended from Rajput kings of North India who fled the bountiful plains of Rajasthan after losing a bloody palace power struggle and hid in the forested eastern foothills of what is now Nepal. The defeated royal warriors took Thebe girls for wives and concubines and, in time, their descendants combined the hallowed surnames of their royal ancestors and tribal mothers to emerge as Sing Thebes" should be left to the fawning astrologers of the now defunct courts of pompous Shahs and Ranas. But I digress.

The second type of marriage forbidden by Limbu tradition is between parties separated by up to five (some say nine) degrees of consanguinity. The definition and degree of consanguinity as understood and practiced by the Limbus is different to those of other groups within Nepal such as Magars, Gurungs and Ranas and those of Europeans.

Let us imagine a Thebe lad named Kaanden who is scanning a mental list of prospective brides. Since he is a Thebe, all Thebe girls anywhere except Sing Thebes are classed as Chelis (sisters) and expected to be treated as such. Even flirting and minor indiscretions (surely an oxymoron) with these Thebe girls would be strictly forbidden and attract severe consequences. In olden times, this basically meant the collective loss of face of the offender's extended family, blood feuds with the girl's own extended family, and the banishment of the offender into "Munglan", the land of the Mughals, i.e. India and Sikkim.

Let us imagine that our would-be bridegroom's  mother is a Menyango. According to Limbu practice, this places the set of all Menyango girls at a distance of one degree of consanguinity. They are off limits to Kaanden and as sacred as his own mother.

Kaanden's paternal grandmother was a Maaden and maternal grandmother a Jabegu. So, any union with Maaden and Jabegu girls would be illicit as they are just two degrees removed, and, yes, Kanden needs to pay the same degree of respects to these girls as due to his own grandmothers. In fact, the prescribed way for Kanden to address these girls is as "grannies".

Kaanden's paternal grandfather's mother was a Lingden and maternal grandfather's mother a Chongbang. This means all Lingden and Chongbang girls are only three degrees removed and out of Kaanden's matrimonial calculus.

This hypothetical case illustrates the complexity of the web of clans that a Limbu has to negotiate to properly observe marriage taboos. Without getting lost in the forest of Kaanden's ancestral extended family, the number of clans, here loosely equated with major surname groups, excluded from Kaanden's marriage suit equals 32. Thirty-two! If nine degrees of consanguinity were to be observed, as is sometimes claimed, this number shoots up to 512. Are there even this many Limbu clans?

In practice, though, I suspect that even five degrees of consanguinity was always maintained on the female, the so-called 'leaf', sides of the family, branching off from mother, grandmother, great grandmother, etc. Though the Limbus have their own script, mass literacy is still a work in progress, and, in the absence of written records, folk memory can retain only so much information.

Late in the afternoon on the Christmas Day, we, along with our visiting friends, drove to a small park in Marrickville, an inner west suburb of Sydney, to mark the rite of passage of a Limbu friend's 10-month-old son. As many as 70-80 Limbus from various parts of the Limbuwan in eastern Nepal had flocked there. I suspect that if we all had taken the trouble to introduce ourselves and map our family trees, most of us would have found some common branches in our family trees, making most of us related by blood as per Limbu tradition.

Tuesday, December 21, 2010

The Mythical Man-Month: Project Management Insights

Frederick Brooks, Jr’s software project management classic, The Mythical Man-Month (The MM-M), continues to be read, debated and entrenched in undergraduate reading lists thirty-five years after its publication. This is surprising in a field where 20 percent of current knowledge is estimated to become obsolete every 12 to 18 months.

To put things in perspective, when the book was first published, computer memory rented at USD12.00 per kilobyte per month. At that rate, the 32GB SD card in my Samsung Galaxy S would have cost over 400 million dollars per month.

One of the reasons behind the enduring popularity of The MM-M is the author’s premise that “managing a software project is more like other management than most ... initially believe”. Brooks, who earned his stripes as the Project Manager for the IBM System/360 computer family and its software, advances “propositions” that would be applicable in almost any non-trivial project, repeatedly hammering the point that project management is about people and teams, not technology.

He buttresses his propositions with war stories drawn from his IBM experience and other contemporary projects. Little wonder, then, that The MM-M continues to attract a motley readership comprising doctors, psychologists, sociologists, lawyers as well as IT professionals.

What are Brooks’ project management insights that have withstood the test of time and continue to be relevant in the new century? Here are some randomly selected teasers from the book, in quotes when copied verbatim, with my own comments in square brackets:

  • The Biblical Tower of Babel project failed due to communication issues

  • “... the essential problem [in project management] is communication”

  • “The crucial task is to get the product defined. Many, many failures concern exactly those aspects that were never quite specified.”

  •  “... adding manpower to a late software project makes the project later”

  •  “... conceptual integrity is the most important consideration in system design” [or project]

  •  “Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations”

  • “The [project] manager will be continually amazed that policies he [sic] took for common knowledge are totally unknown by some member of his team”

  • “The total cost of maintaining a widely used program is typically 40 percent or more of the cost of developing it. Surprisingly, this cost is strongly affected by the number of users. More users find more bugs.”

  • “The fundamental problem with program maintenance is that fixing a defect has a substantial (20-50 percent) chance of introducing another”

  • “Many poor systems come from an attempt to salvage a bad basic design and patch it with all kinds of cosmetic relief.”

  • “How does a project get to be a year late? ... One day at a time” 

  • “When one hears of disastrous schedule slippage in a project, he images that a series of major calamities must have befallen it. Usually, however, the disaster is due to termites, not tornadoes ... ” [As the saying goes, for want of a nail, the kingdom was lost]

  • “I believe the hard part of building software to be the specification, design and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.” [author’s emphasis. He means coding by ‘representing’. The author contends that fidelity to specification is pointless if the specification itself is flawed]

  • “The hardest single part of building a software system is deciding precisely what to build ... For the truth is, the clients do not know what they want ... So ... it is necessary to allow for extensive iteration between the client and the designer as part of the system definition.”

  • “In my experience most of the complexities which are encountered in systems work are symptoms of organizational malfunction. Trying to model this reality with equally complex programs is actually to conserve the mess instead of solving problems”

  • “Chemical engineers have learnt not to take a process from the lab bench to the factory in one step, but to build a pilot plant to give experience in scaling quantities up and operating in non-protective environments.” [author’s emphasis]

  • “The second [project] is the most dangerous system a person ever designs; the general tendency is to overdesign it ... using all the ideas and frills that were cautiously sidetracked on the first one.”

  • “My rule of thumb is 1/3 of the schedule for design, 1/6 for coding, 1/4 for component testing, and 1/4 for system testing” [This means testing should be assigned half the schedule time. Coding gets the least amount of time]

  •  “Schedule disaster, functional misfit, and system bugs all arise because the left hand doesn’t know what the right hand is doing. Teams drift apart in assumptions.”

Saturday, December 18, 2010

Deconstructing an SQL snippet

Recently, I came across the following snippet in a Teradata SQL script that came my way:

select calendar_date
from sys_calendar.calendar
where Calendar_Date Between
(((ADD_MONTHS(DATE,-1)) /100) *100 +1) (DATE)
AND (((((ADD_MONTHS(DATE,-0)) /100 ) *100 +1) (DATE)) -1) (DATE);

I knew that Teradata, just like Excel, internally saves dates as integers but did not remember the conversion scheme. A quick search later, I had the formula:

Integer Date = (YEAR – 1900) * 10000 + (MONTH * 100) + DAY

So, Teradata internally saves today’s date, i.e. 2010-12-18, as 1101218. Here, year = 110 (110 years since 1900), month = 12 and day = 18.

Now, it was just a matter of taking the expressions apart piece by piece, starting from the innermost expressions.

In the line “(((ADD_MONTHS(DATE,-1)) /100 ) *100 +1) (DATE)”, the function ADD_MONTHS(DATE, -1) is merely adding -1 month to today’s date. Since today is 2010-12-18, the function returns 2010-11-18. It’s internally saved as 1101118.

The result of ADD_MONTHS(), 1101118, is divided by 100. This is an ‘integer’ division and results in 11011. The division removes the day part. If one tries to cast this number to date, Teradata complains, predictably.

In the next step, 11011 is multiplied by 100 to restore the day part, resulting in 1101100. However, there is something seriously wrong with 1101100 as it has ‘00’ for day part, which is illegal. This is why 1 is added to the result of (ADD_MONTHS(DATE,-1)) /100 ) *100 to give the first day of the previous month. The final '(DATE)' merely casts the integer to date.

So, all that the expression “(((ADD_MONTHS(DATE,-1)) /100 ) *100 +1) (DATE)” is doing is calculating the first day of the previous month. Similarly, the expression “( ( (((ADD_MONTHS(DATE,-0)) /100 ) *100 +1) (DATE) ) -1) (DATE)” calculates the last day of the previous month. It first calculates the first day of the current month and subtracts 1 day from it, which results in the last day of the previous month. (The ADD_MONTHS() function is redundant in the second expression as it is basically doing nothing except confound users).

Coincidentally, I had previously written a more intuitive way of achieving the same result. It has the virtue of not using magic numbers:


SELECT CALENDAR_DATE
FROM SYS_CALENDAR.CALENDAR
WHERE CALENDAR_DATE BETWEEN
ADD_MONTHS(CURRENT_DATE, -1) - EXTRACT(DAY FROM CURRENT_DATE) + 1
AND CURRENT_DATE - EXTRACT(DAY FROM CURRENT_DATE);