Photos and write up - Thekkady and Munnar - May 2007

I did this trip to Thekkady and Munnar, Kerala, India in May 2007 and  what follows is a write up of the more interesting  facets of the trip, along with some very interesting photos. All the time, this was just circulated as a mail to friends and people interested and is back in my blog because i am bored forwarding the mail and photos. - Warning big post ahead--

Sleeping in a tree house in pitch darkness: Having been brought up in a village, I am more used to dark nights. So darkness was not totally new to me. But this was too real. you could feel it. you could even touch it if you wanted. It was so thick and engulfed me that i wondered if it would prevent me from moving around- a kind of very viscous fluid. If some person or animal or an object was a feet away, you couldn't see them.

I wanted to describe the darkness as day being painted with a huge container of pitch black paint. Then stopped when i realized that that is what nature had actually done. :) Back in the city, where night is turned into day with all the lights on and where you couldn't even see the stars, i understand that no amount of explanation will do to a city dweller.You have to just experience it.

We had to walk to the tree house from our home stay. We had a torch (very powerful, something similar to surefire) and the tree house also had electric lights that were switched on. There were 3 CFL bulbs to be precise, 2 on the front and back of the house and one inside. We were warned to keep the lights on when we slept. When we entered the house (a misnomer as it was a 10x10 feet room), a spider just went out of the other door. It was precisely for this reason, we were asked to keep the lights switched on, i.e. ward off the insects. But the lights also attracted lot of moths and other similar insects. So we had to switch it off. When you are bone tired with a day’s activity, all you need is a place to sleep. Nothing else really matters and i slept soundly.

This is the tree house.

Tree House

Trekking through leech infested forest; The other scary part of the trip was the leeches we encountered during our trek within GAVI forest adjacent Periyar Tiger Reserve.  This is a beautiful place. you need a permit from the forest department for this trip and you have to travel through the forest in a jeep. We stopped the jeep and walked a 100 metres for this shot of elephants. There is also a kid elephant which is hidden. We had some frightening moments when we took this shot.

Elephants

We crossed the lake here in a boat and started the trek from the other side.

Lake in Mist

Please refer the photo 'checking the socks' When we were told to wear the socks, I didn’t take that seriously. It is L shaped and runs all the way till our knee. We had to wear that over our socks and our trousers should be tucked inside. (Refer the photo). The shoe was worn on the top of it. The socks were layer 1, the leech socks were layer 2 and the shoes, layer 3. This arrangement was thoroughly checked before we started. Some 500 meters into the trek, my sister-in-law (SIL) screamed saying that there are lots of leeches all over, our shoes and pants. The guide took out some salt from a 1 Kg salt pack that he carried in his back pack and applied some salt where the leeches were clinging to our shoes and trousers. The leeches fell down and died.

Checking the socks

It was then that I noticed that there were literally thousands of leeches all over the leaf covered floor of the forest. The guide told us that it was normal and asked us to continue. But my wife and SIL were too scared to continue and wanted to return (they returned back after some 1.5 kms into the trek). Even I was very scared, but wanted to continue the trek. May be I didn’t want to look like a coward in front of my wife and SIL :). May be I got lot of courage from others who were continuing the trek. But whatever it was, the following is the major reason for my fear.

The leech is a like a miniature trunk of an elephant. The broader sticky side, clings to a (ny) surface and the narrow (pointed) side, searches for a surface to suck blood from. This end of the leech moves like an elephant trunk. And the body of the leech is so elastic that it expands and contracts to 1/4th or 1/5th of its original size. When a leech that is completely expanded in search for a surface, contracts to 1/5th its original size, it looks as if the leech has entered the surface. A leech had clung to my cargo pant close to my left hand side pocket. When I saw the leech contracting, I thought that it has entered my pant. This was the reason for my fear.

The guide told me that leeches can’t pierce a surface and enter it and that we were safe unless there is an opening in our trouser or socks. After this my fear subsided. Even then, we stopped at least four or five times to apply salt on our shoes and check our dresses. It was then that I realized that we should not be wearing sneakers like NIKE or ADDIDAS. These are no good in this kind of terrain and we should have been wearing proper trekking boots. I was fortunate that the leeches didn’t enter my shoes, but the people who came with me were not that fortunate.

Big Tree

The terrain was very uneven and the trek was also very demanding.  we came across some big trees and 'big tree' is a shot of such trees.The place where we checked the leech socks was was a rocky part and this was the only place where we were allowed to check the shoes (by removing) and dresses (by loosening). The guide told us that the probability of being attacked by a leech when we are walking fast is quite less. Our group was fortunate that we were not attacked even a single time by a leech. The problem with a leech attack is that it is totally painless. One doesn’t feel the pain of an attack, unlike a mosquito bite.

Here is another elephant that we shot. This was taken in the evening and the guide told us that this is an old elephant. The elephant didn't care about our presence and was happily munching away. May be she had enough of visitors for the day and didn't want to see one more.

When i reminisced about  the trip later, i can confidently say i some what understand and completely appreciate the pain people take to shoot photos and documentaries in tropical forests, the kind shown on National Geographic or Animal Planet. I will definitely do the trek again, if I get a chance.

We also visited Eravikulam national park in Munnar and took some shots of the endangered Niligiri Tahr (Mountain goat).  Transport is not allowed beyond a point and we had to walk to the top. The funny part is that on the way to the top, i was searching for the Tahr to get some photos and with great difficulty managed to get a few and the mist also made it difficult . Here is a silhoutte.

Tahr - A silhoutte

By the time trekked and reached the top, the mist had cleared and the view was better. May be they were serious when they said that the view from the top is always better :). Also, to my great surprise i did come across a few very camera friendly Tahrs.  These Tahrs didn't run away when humans approached and were patient enough to pose for photos :)  Here is the more domesticated Tahr posing for Photo.

Camera friendly Tahr :)

Technical Debt- Manager's perspective

This is the second article on technical debt and looks at Technical Debt from a Manager’s perspective. Click here for the first one. It helps if you read the first article before you proceed with this.

To start with, a few points on technical debt that are obvious.
    # Technical Debt is bad and should be treated like normal financial debt
    # Normal practice must be to do good design and write good code (as expected by the definition of good software).
    # If your system incurs technical debt, it should be for a genuine reason and at the first chance, the debt should be serviced.

#1 It is perfectly possible to write code/create an software product without incurring technical debt. This should be the aim of any project manager, software architect and developer.

#2 When you have to incur technical debt, out of the four quadrants of technical debt  as categorized by Martin Fowler, the quadrant Deliberate/Prudent is acceptable.

Types of technical debt. (image courtesy- Martin Fowler’s Site)

For people who question this decision to call only the Deliberate/Prudent quadrant as acceptable, I request them to look into the explanations given in each of the quadrant. Going through the explanation makes it clear that other quadrant technical debts don’t conform to the definition of creating good software. If a person's idea of Technical debt falls in the other quadrants, you can be sure that people are using the term technical debt to hide their ignorance or incompetence or just being un professional.

#3 There is one exception to the above definition/rule..If as a manager, you/your company has taken over a product with a messy code base. In such a scenario, I believe it is ok for people to use the word technical debt to quantify the effort involved (which can be translated into a $ value) to bring back the quality of the code base in line with the definition of good software.

#4 Technical debt should be one of the key factors that influence a decision when a company wants to acquire a software product.. the reason for it's importance is explained in #5.

#5 If an entity(manager/company) takes over a product without factoring in technical debt, but later realize that that the product has high technical debt, this makes faster code changes, easier testing and hence faster releases difficult.

Then one of the following options have to be choosen from.
#5.1 Pay back the technical debt along with interest in a single go – this is usually not a viable proposition economically as the product may have to go without any new releases for the whole duration the debt is paid back.
#5.2 Gradually payback the technical debt and improve the quality of the product. – this makes more of a commercial sense as the debt is paid back in smaller chunks and the quality of the code base keeps increasing. On the flip side, this approach takes a longer period of time.
#5.3 Else retire the product, if the above options aren't possible, since maintaining it is no longer an economically viable solution.

#6 Cost of NOT serving technical debt is more than Cost of Serving technical debt: Taking the definition of good software product (as any software that can be modified and tested, with minimal effort), the cost of servicing the debt typically will include fixing the coding standard violations, refactoring the design and code, taking care of cyclomatic complexity and in- adequate test coverage.

If a person looks at the cost of not servicing the technical debt, this will include the following.
    # Additional overhead on customer support.
    # Executive time spent in managing un happy customers
    # Opportunity cost of missed releases
    # Loss in market share due to less frequent releases
    # Impact on market share,
    # Intangibles like loss in reputation
Since the cost of servicing as well as not servicing has an impact on RoI , a company should consider technical debt as a key parameter to arrive at an informed decision when it comes to evaluating a software.

#7 Cost of Change for Products with Technical Debt. Let us look at the product life cycle of an optimal software product (as defined by software that can be modified and tested with minimal effort) and a software product with high technical debt.

The cost of change for a product with high technical debt is more compared to an optimal product , as shown in the diagram below.

CoC and Customer Interest Vs Time

Please note that here we assume that the optimal product as well as the product with high technical debt both continue to get enhanced for the same amount of time. This is not true in reality as we will further see in the article. The reason why the customer interest in the product keeps decreasing is that the higher cost of change makes it more difficult for new features  implemented and at a faster rate.

#8 Longevity of a software product with higher technical debt is actually lesser compared to the optimal software product ( as explained in the graph below). This is because the product is never allowed to mature feature wise and also as the higher technical debt makes it difficult to keep it alive. This mostly results in early retirement of the product.