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.

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.”

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);

Running with a Metaphor

This year, I took part in three fun runs and may yet participate in one more before the year wraps up. My most recent dash was at the Brighton Beach Fun Run on October 17, in which I managed to reel in and out-kick the fastest pace-marking green dragon in the last 2/3 hundred meters. My official time for the 10k event was 40 minutes and 4 seconds.

In the Blackmore Half Marathon on Sept 19, I clocked 90 minutes and 3 seconds and, earlier on Aug 8, I completed the 14.1 k City2Surf in 62 minutes and 44 seconds. Not bad for a recreational runner who pounds the dirt only 3/4 times a week. Having said this, I would dearly love to improve my times by a couple of minutes next year.

Why run? More specifically, why run in fun runs? Personally, I find running in a vacuum mentally and physically tough and unsustainable in the long term. I need some sort of goal in order to motivate myself to lace up my running shoes and hit the road regularly.

In the lead-up to the Blackmore Half Marathon, I ran a half marathon every week for 5/6 weeks, one of them at work before a late morning team meeting in which I turned up feeling slightly dizzy and nauseous. Right after the Blackmore Half Marathon, I felt drained of all motivation and will power to run half marathons, which I have done only once since. This is where fun runs come in. They provide an excuse and catalyst to go out there and run week in and week out, helping to raise funds for charities at the same time.

I specially love the final week before a race day and the race day itself. Runners typically taper down in the final week or two before the big day, which basically means scaling back training and allowing the body to rest. On the day before the race, there is the delightful ritual of assembling the running gear, securing the bib and timing chip, arranging transport, and resting and drinking a lot of water.

On the race day itself, you see a lot of runners on the streets and public transport, some of them garbed in expensive lycra running rags and heart-rate monitors, and most of them bristling with bibs, timing chips and that quintessential trapping of all image-conscious modern runners - iPod.  Even though most fun runs are just that - fun runs - you sense tension in the air as most runners would be aiming for some kind of 'PB' (personal best), which may be nothing more ambitious than finishing the race.

Walking along the streets with other fellow runners, sharing public transport in expectant silence or milling about in the crowd waiting for the starter gun to fire, one feels a keen sense of kinship with other runners, all of whom would have busted their lungs and legs for weeks and even months to be where they are. In the early morning air, with limbs taut with coiled energy, one feels this adrenaline-laced cocktail of anticipation, tension and excitement that alone makes all the solitary runs worth the while.

A View Of Taishan

By Du Fu

What shall I say of the Great Peak? --

The ancient dukedoms are everywhere green,

Inspired and stirred by the breath of creation,

With the Twin Forces balancing day and night.

...I bare my breast toward opening clouds,

I strain my sight after birds flying home.

When shall I reach the top and hold

All mountains in a single glance?

My Country

By Dorothea Mackellar (1885 - 1968)

The love of field and coppice,

Of green and shaded lanes.

Of ordered woods and gardens

Is running in your veins,

Strong love of grey-blue distance

Brown streams and soft dim skies

I know but cannot share it,

My love is otherwise.

I love a sunburnt country,

A land of sweeping plains,

Of ragged mountain ranges,

Of droughts and flooding rains.

I love her far horizons,

I love her jewel-sea,

Her beauty and her terror -

The wide brown land for me!

A stark white ring-barked forest

All tragic to the moon,

The sapphire-misted mountains,

The hot gold hush of noon.

Green tangle of the brushes,

Where lithe lianas coil,

And orchids deck the tree-tops

And ferns the warm dark soil.

Core of my heart, my country!

Her pitiless blue sky,

When sick at heart, around us,

We see the cattle die-

But then the grey clouds gather,

And we can bless again

The drumming of an army,

The steady, soaking rain.

Core of my heart, my country!

Land of the Rainbow Gold,

For flood and fire and famine,

She pays us back threefold-

Over the thirsty paddocks,

Watch, after many days,

The filmy veil of greenness

That thickens as we gaze.

An opal-hearted country,

A wilful, lavish land-

All you who have not loved her,

You will not understand-

Though earth holds many splendours,

Wherever I may die,

I know to what brown country

My homing thoughts will fly.

Correlated Subquery

The NULL issues discussed in the previous entry on subquery can be side-stepped with correlated subqueries. Correlated subqueries are different to subqueries in that for each outer row, the query tries to find a matching inner row. If such an inner row exists, then the outer row is returned. For example,

select *
from t1
where exists
(select *
from t2
where t1.a_col = t2.a_col);

The above query can be optimized as follows:

select *
from t1
where exists
(select '1'
from t2
where t1.a_col = t2.a_col);

Notice that the inner query projects the value '1' if there is a match instead of the whole row, which could have dozens of columns.

What happens if the WHERE clause has NOT EXISTS instead of EXISTS, and the inner query returns NULL? In that case, the outer query returns nothing, which is the expected behavior. Presto, the perils of NULLs are nullified!