The Anarchy - by William Dalrymple

I knew it will be a painful read the moment I picked up this book in the library. This one is about how the East India Company came to India for trade and paved the way for the British to rule the country till 1947.

Every Indian knows the history - or at least a part of it. But you are too young to be affected by it during your school days. It all happened in the past. For most of us who were born into the 70s and beyond, our parents wouldn't even have known about the British Raj. Sure, the grandparents would have lived through the era. But unless they had taken part in the freedom struggle, that wouldn't have come up during the conversation during the summer holidays. It didn't, at least for me and my brother.

So, it came as a surprise that the company's office in England was so unassuming that passersby wouldn't have believed it if anyone had told them that it belonged to the East India Company. It came as a surprise that the company failed in its initial attempts to set shop here. I recall pausing during my reading to wonder how different India's destiny would have been if the British had given up and left. It was amusing to read that the original map of Mumbai was lost during the sea voyage of the Portuguese princess in whose wedding the islands had passed into the British hands. I chuckled when I read that there was much confusion about the exact location of India in Britain of that time and some Englishman actually believed that it was somewhere near Brazil. 

But my surprise and amusement didn't last long as I read about the company solidifying its base and implementing its 'Divide and Rule' policy. I read in horror and disbelief as the Indians turned against their own, displaying the basest side of humanity - hatred, greed and selfishness. If only all of us had banded together. If only - 2 words that could have changed history but could not. 

I had to skip reading entire chapters as it was too much to read about betrayals, murders and looting. As a Maharashtrian, it was especially painful to read about the Marathas setting cities on fire and raping women. 

At one point, I seriously thought about returning the book. But didn't. My returning the book was not going to change the history. Nothing that anyone does now, can. All that we can do is learn from it and make sure not to repeat the mistakes.

But as I look at what is happening around me these days, I think a snowflake will have a better chance in hell. We are, as a nation, perhaps doomed to repeat our history. The only difference is that we ended up being ruled by the outsiders back then. 

Death In The East – by Abir Mukherjee

I have always been fascinated by the British Raj. It might be a politically incorrect statement in today’s India. Of course, as an Indian, I am not fond of the 150+ years of rule, tyranny and oppression that the British wrecked in this country. But since I believe that the apathy and greed of most of the Indian royalty and general populace alike, was equally, if not largely, responsible for allowing the British to first gain a foothold, and then to flourish in this country, I do not look at that era with pure hatred.

To cut a long story short, when I read that this novel is set in the British Era I did not think twice before checking it out.

This is the 4^th in the Wyndham & Banerjee series of crime novels. The plot keeps alternating between 1905’s London and 1922’s Assam. Captain Sam Wyndham has come to Jatinga, a remote village in Assam, as a final resort, to rid himself of his opium addiction. But his past does not seem to let go of him. As he endures the grueling detoxification regime at the Ashram, his mind keeps flashing back to his time in Whitechapel, an area in London’s East End. The enormous guilt of not having been able to save his one-time sweetheart, Bessie Drummond, so many years ago plagues him now more than ever.

And then death comes knocking once again. This time, at the Ashram’s door when a fellow patient is found dead in a stream. The jury is still out on whether it is a murder or an accident. As Wyndham completes his treatment and goes out to spend a few days with another Britisher in Jatinga, the quaint village is rocked by yet another death – that of a very wealthy and powerful man. However, this man has a connection with Wyndham’s past. A connection that Wyndham would do anything to forget. Though this death, by all accounts, seems to be a natural one, Wyndham cannot quite shake off his suspicion that it is anything but that. Luckily for him, in an answer to his earlier letter, his Sergeant, Surendranath (or Surrender-not!) Banerjee, arrives in town in time to help him unravel this mystery.

The novel keeps you engaged as you try to work out who could have killed Bessie, if the death of the patient is an accident and who, if anyone, killed beautiful Emma’s rich husband. The novel has intermittent references to events from India’s freedom struggle like the non-cooperation movement and the Chauri-Chura incident. We all know that Indians (and dogs!) were not allowed in the British clubs set up in India. But the references can still rile you. The author has managed to beautifully capture both - the earlier camaraderie between Sam and Surendranath and Sam’s later realization that though most of it is intact, a subtle but sure change has crept in.

I suspected that the library does not have the first 3 books of this series – because if they had had them, the assistant would have handed me the first one instead. When I went to return the book, I inquired and my suspicions were confirmed. I told them that I liked this one a lot and to let me know in case they bought the others.

Let’s see if I get to read more of the Wyndham-Banerjee, or should I say Banerjee-Wyndham, stories.

A Patchwork Quilt – by Sai Paranjpye

I have always been fascinated by theatre –the plot, sets, costumes, lighting and of course, acting. So, when I saw this memoir by Sai, I immediately checked it out. And I am delighted to say that I was not disappointed.

Sure, Sai does not lay out her life’s story in a neat chronological fashion. She cannot remember exact dates or years, she confesses candidly. But that does not take anything away from the narrative. We get to read about her childhood, her days in NSD and All India Radio, the plays she wrote and directed for children and adults, the documentaries that she directed, her stint with Doordarshan and CFSI and her film career. She tells us about the people she worked with, the hardships and the triumphs. We come to know about how a play gets written, directed and produced. We are treated to interesting anecdotes about people we have been seeing for years on TV and on the celluloid screen. All this with a healthy dose of tongue-in-cheek humor. The memoir is a fascinating read for anyone who is interested in plays and movies.

I smiled when I came across references to the movies – Jadoo Ka Shankh and Sikandar. These movies had been screened at our school. And I had loved them😊

I am ashamed to say that I have not watched a single one of Sai’s movies. But I am determined to watch at least the light-hearted ones. I especially want to see her movie Papeeha as forest conservation is another subject close to my heart.

I only wish that I had read the original memoir in Marathi, instead of its English translation.

Madam Prime Minister – by Seema Goswami

I was in the library after a very long gap. Hard to believe that there was a time when I used to go there to borrow books every week, every month. Then this was no longer the case. For some months I was pressed for time. The enthusiasm to read was simply not there for a few more months. And the rest of the months were gobbled up by the pandemic. But then, all of a sudden, the books called me back. In India we believe that to be able to visit an important shrine, like e.g. Vaishno Devi, the invitation has to come from the Deity herself. Perhaps it is the same for books.

So, there I was. Nudged also by the WhatsApp messages from the library staff who dutifully kept informing me about the new arrivals. I stared at the messages wistfully for days and finally succumbed to the temptation😊On my way there, I kept telling myself that I need to borrow a book in Marathi. I am woefully illiterate when it comes to reading literature in my own mother-tongue.

But then it would have taken some time to look for a Marathi book. So, I told myself that I will do that one Sunday morning. And then, free from the guilt, started looking through the English books when I caught sight of this book. The plot seemed promising and so I checked it out.

Like I said, it has been a month since I read this book. So, I do not remember much of it except for the fact that I did not like it much. Though India has had a prime minister who came to power at a young age, was derided by her own party veterans as Gungi Gudiya (a dumb doll!) and went on to become a force to be reckoned with, the character of Asha Devi who becomes prime minister after the assassination of her father did not appeal to me. The details of her affair with her finance minister felt like an attempt to add the customary ‘sex factor’ to the book – similar to why an item number is added to a Hindi movie, irrespective of the the main plot. It did nothing to add to the story. And I am rather tired of reading about the central female characters who are too beautiful to be real.

The only thing that resonated with me was the fact that it does not take a long time for someone to become adept at the game that is politics. You may start as a naïve one, but you sure do not end up as one.

Pragmatic Unit Testing- Andrew Hunt & David Thomas

This book is from 2003 so a bit dated but I read it for concepts. And I found plenty of them.

First of course is a handy way to remember the six specific areas to test - RIGHT -BICEP! Before you go trouping to the friendly neighborhood gym to lift the barbells, here is the breakdown -

Right . Are the results right?

B . Are all the boundary conditions CORRECT?

I . Can you check inverse relationships? For instance you might check a method that calculates a square root by squaring the result, and testing that it is tolerably close to the original number You might check that some data was successfully inserted into a database by then searching for it, and so on. Of course you have to guard against the possibility that there could be a common error in original routine and its inverse, thus giving correct results. So if possible, use a different source for the inverse test.

C . Can you cross-check results using other means?

E . Can you force error conditions to happen?

P . Are performance characteristics within bounds? e.g. time taken to execute method as data size grows. So execute method with data of different sizes and check that the time taken is within acceptable limits.

Right. Next, we all can vividly recall an incident or two when the developer forgot to test a boundary condition, resulting in much heartburn all around. So here's a handy way to get it right - the acronym CORRECT.

Conformance . Does the value conform to an expected format?
Ordering . Is the set of values ordered or unordered as appropriate?
Range . Is the value within reasonable minimum and maximum values?
Reference . Does the code reference anything external that isn't under direct control of the code itself?
Existence . Does the value exist (e.g., is non-null, nonzero, present in a set, etc.)?
Cardinality . Are there exactly enough values? 0-1-n rule
Time (absolute and relative) . Is everything happening in order? At the right time? In time? Are there any concurrency issues? What is the order of calling sequence of methods? What about timeouts?

Another important thing to be kept in mind is when to use mock objects. The book mentions list by Tim Mackinnon:

- The real object has nondeterministic behavior (it produces unpredictable results; as in a stock-market quote feed.)
- The real object is difficult to set up.
- The real object has behavior that is hard to trigger (for example, a network error).
- The real object is slow.
- The real object has (or is) a user interface.
- The test needs to ask the real object about how it was used (for example, a test might need to check to see that a callback function was actually called).
- The real object does not yet exist (a common problem when interfacing with other teams or new hardware systems).

The three key steps to using mock objects for testing are:
1. Use an interface to describe the object
2. Implement the interface for production code
3. Implement the interface in a mock object for testing

Then there are properties of good tests i.e. A-TRIP - Automatic, Thorough, Repeatable, Independent and Professional (encapsulation, DRY principle, lowering coupling etc.)

For those who are wondering about where to keep the test code, the author provides a few suggestions:

1. The first and easiest method of structuring test code is to simply include it right in the same directory alongside the production code. Though this will allow classes to access each other's protected members for testing purpose, it clutters production code directory and special care might need to be taken while preparing releases.The next option is to create test subdirectories under every production directory.This gets test code out of the way but takes away access to protected members. So you will have to make test class subclass of the class that it wants to test.

2. Another option is to place your Test classes into the same package as your production code, but in a different source code tree. The trick is to ensure that the root of both trees is in the compiler's CLASSPATH. Here the code is away from production code and yet has access to its protected members for testing.

Following advice needs to be kept in mind as you go about testing:

1. When writing tests, make sure that you are only testing one thing at a time. That doesn't mean that you use only one assert in a test, but that one test method should concentrate on a single production method, or a small set of production methods that, together, provide some feature.

2. Sometimes an entire test method might only test one small aspect of a complex production method.you may need multiple test methods to exercise the one production method fully.

3. Ideally, you'd like to be able to have a traceable correspondence between potential bugs and test code. In other words, when a test fails, it should be obvious where in the code the
underlying bug exists.the per-test setup and teardown methods and the per-class setup and
teardown methods.

4. When you find bugs that weren't caught by the tests, write tests to catch them in future. This can be done in 4 steps - Identify the bug. Write a test that fails, to prove the bug exists. Fix the code such that the test now passes. Verify that all tests still pass

5. Introduce bugs and make sure that the tests catch them.

6. Most of the time, you should be able to test a class by exercising its public methods. If there is significant functionality that is hidden behind private or protected access, that might be a warning sign that there's another class in there struggling to get out. When push comes to shove, however, it's probably better to break encapsulation with working, tested code than it is to have good encapsulation of untested, non-working code.

7. Make the test code an integral part of the code review process. So follow this order:

- Write test cases and/or test code.
- Review test cases and/or test code.
- Revise test cases and/or test code per review.
- Write production code that passes the tests.
- Review production and test code.
- Revise test and production code per review

8. While coding if you can't answer this simple question - how am I going to test this - take it as a signal that you need to review your design.

9. Establish up-front the parts of the system that need to perform validation, and localize those to a small and well-known part of the system.

10. Check input at the boundaries of the system, and you won't have to duplicate those tests inside the system. Internal components can trust that if the data has made it this far into the system, then it must be okay.

11. Cull out individual tests that take longer than average to run, and group them together somewhere. You can run these optional, longer-running tests once a day with the build, or when you check in, but not have to run them every single time you change code.

12. Unit tests should be automatic on two fronts - they should be run automatically and their results should be checked automatically. The goal remains that every test should be able to run over and over again, in any order, and produce the same results. This means that tests cannot rely on anything in the external environment that isn't under your direct control. Use Mock objects. Tests should be independent from the environment and from each other.

Finally, following list can be handy in checking for potential gotchas involving checked-in code:

- Incomplete code (e.g., checking in only one class file but forgetting to check in other files it may depend upon).
- Code that doesn't compile.
- Code that compiles, but breaks existing code such that existing code no longer compiles.
- Code without corresponding unit tests.
- Code with failing unit tests.
- Code that passes its own tests, but causes other tests elsewhere in the system to fail

Manage Your Project Portfolio - Johanna Rothman

I just finished reading this book and I am glad I read it because it gave me a lot of valuable tips about finishing key projects on time.Just jotting down important points here for future reference......

The fundamental thing to keep in mind is that unless you have information on all the work that you are expected to do you cannot possibly think of finishing the most important things on time. So the first step is to create a project portfolio. Nothing fancy is needed. Just one bucket each for next 4 weeks + one bucket each for next 3 months as columns i.e. total 7 columns. List each of your resources as rows. And in the cell list what project and what feature that resource will be working for that duration. Another key thing to remember is that portfolio monitoring can best be done in an agile environment. Waterfall methodology doesn't provide data needed till the whole work is done....or not done. Following 5 types of work needs to be included - periodic (i.e. done every week or month or quarter), ongoing work, emergency work, management work and project work.

Then at a set frequency (every month or quarter), this folio needs to be reviewed. You have to make one of the following decisions for each project - Commit (this is full commitment, not partial), kill or transform. The projects to be committed to can be ranked based on point system (out of a total, say 10000, points keep assigning points to projects and staff them in the order from highest to lowest), risk or cost (in both these cases a few iterations would be needed to give some idea about the velocity so total cost or risk can be projected) or customers for whom the projects will be delivered (business value). Other ways of arriving at ranking are pairwise comparison, single and double elimination and your product's position in the market place ( features needed to be added to close the chasm between early adopters and early majority rank high).

Important thing to be kept in mind is that you should not do the ranking alone - do it with peers so you will consider all aspects or at least more of them along with doing what's best for your organization. Of course, you need to run it by your superiors for a final confirmation. And don't rank based on ROI, unless you are a custom development group. Also keep in mind that sometimes some internal projects like e.g. fixing the build or auto-testing system can rank higher than external projects because the payoff will be big. If necessary, consider the organization mission, if you have any, do help narrow down the priority of the projects. Chapter 11 on drafting mission - be it your group's or organization's - is a must-read even if the company that you work for has a formal mission.

Review quarterly at least for serial development. For iterative or incremental development, review every time a feature chunk is done or a prototype is completed. You need a demo and data i.e. the team's velocity since last such evaluation to make a decision about the fate of the project. Also you need to take into consideration, project obstacles and organization strategy. So have the right people at the meeting who have this data and authority to make decisions.

So basically it will help to ask following four questions at the evaluation meeting - does the project fit the organization strategy? What's been done since last evaluation (demo will answer this)? How is the team places with respect to the product backlog (velocity and backlog burndown chart answer this)? What obstacles is the team facing (this will give you a measure of risk involved in continuing the project in the same way). If your organization tracks project cost, you’ll need to also know the run rate (the cost of the project per unit time), the total project cost, and possibly the monthly/quarterly/yearly project cost data.

Other trigger points to review your portfolio are - when release dates change, when your customers want something new, when your competitors announce or release new products, or when new technology is possible. Since these events cannot be predicted in advance, a bit of flexibility is needed as far as folio evaluation goes. Allocate time for exploratory work when you do portfolio evaluation.

The ideal time to review the portfolio is:

• When a project finishes something you can see (the project cycles)

• When you have enough information about the next version of a product (the planning cycles) 

• When it’s time to allocate budget and people to a new project (the business cycles)

Rothman gives two more golden rules. One that we project managers have known since the dawn of time -  that multi-tasking does more harm than good. And two, make decisions as late as possible so you get time to consider many aspects of the situation and changing scenarios to make the best decision. A note about budgeting - Budget target is set for a year but funds are allocated for 3 months. Have a fixed budget for a fixed time and see how many features can be developed.

Keeping a parking lot of projects is also another good idea. The book describes two more concepts - using Kanban and Minimum Marketable Features (MMF). There is some material on fixing the queue length, work size and work cost but I am in favor of fixing the timebox duration. I don't think the other 3 things can be fixed in any meaningful way in an average project.

Project managers often wonder which are the best measures to a project's health. Rothman provides the answer in a no-nonsense way.The only two things that need to be measured are team velocity (current and historical) and product backlog burndown chart. Another thing that can be measured is cumulative flow i.e. work in progress over time compared to the total project scope. The more work in progress, the less this project has provided value to the organization.

There are a couple of points from the book that I find rather far from being practical such as not taking time to put in place an overall architecture but rather letting it evolve as the iterations proceed. You will need a highly sophisticated and experienced team to do that - something which most of us cannot have. Another one, of course, is working with colleagues to make sure everyone is pulling in the direction that's best suited to the organization's goals. This is easier said than done. There is a lot of politics out there and it is not easy to navigate that to make it possible for people to even consider such a notion. Measuring team productivity instead of an individual's sounds about right theoretically but not practically.

That said, I think this is a book worth keeping on your book-shelf if you happen to be responsible for managing a project and a team.

Yudhisthira: The Unfallen Pandava - Mallar Chatterjee

Besides being a huge fan of any novels about ancient secrets, I love books by Indian authors that interpret Indian mythology in a new way e.g. offerings by Amish Tripathy and Krishna Udayasankar. As far as the epic Maharbharata goes, Bheem and Arjun have cornered major portion of Pandava's fame. The eldest sibling, Yudhisthira, though portrayed as the epitome of virtue and justice, has never been able to shake off the stigma of being the one to wager, and lose, his wife in a game of dice. That single act has eclipsed his whole character.

So when I saw this book on the library aisle I wondered about what new interpretation the author has managed to give to the tale of Mahabharata in general, and to this much-maligned Pandava in particular. Alas! I was in for a mighty disappointment! This thick book simply narrates the old story, with a few stray sub-stories that you probably would have missed during your childhood days. No new interpretation whatsoever. Why the author felt the need to retell the old story, which almost every Indian knows by heart, I cannot fathom. In my humble opinion, the book also fails to adequately address the range of emotions that Yudhisthira must have felt, his struggles and conflicts, his dilemmas and doubts, his wins and failures. It simply doesn't tale his side of the story fully.

I rarely fail to finish any book. But I stopped reading this one even before I reached the halfway mark. If I have to read the epic itself, there are far better sources. :-(

Keepers Of The Kalchakra & The Sialkot Saga - Ashwin Sanghi

As mentioned before on this blog, I found myself getting rather tired of the plots, characters and stories woven by Western authors. So I turned to the Indian ones - specifically to Ashwin Sanghi. I had seen his books many times in the library but had never reached for one. I decided to give them a try and checked out 'Keepers Of The Kalchakra'.

To be sure, it has been more than a month since I read the book so my recollection of the details is more than a bit hazy. I remember, though, that the plot was extremely interesting. The book, however, seemed very long-winded. Parts of it were too theoretical for my taste. Towards the end, I found myself checking out how many pages are left. As far as the characters go, I must confess that it felt strange to get used to characters with Indian names. How I wish the author hadn't mentioned that the protagonist Vijay has flecks of dandruff in his hair. Every time Vijay was mentioned I kept seeing dandruff in his head :-( I was almost afraid sooner or later I will come across product placement of Head & Shoulders! The Russian scientist drove me nuts with his incessant 'Do you know about' questions. Anyone following world politics even for a bit would laugh at the possibility of an agent of RAW being included with agents of CIA and Russia's FSB in any task force. But this is a book by an Indian author so it's his world and his characters. That said, why must Russian agents be portrayed with only the interests of Mother Russia in mind, the rest of the world be damned? And why can't the RAW agent be shown consumed by the same zeal? I am tired of the stereotypes. Of course, if the Indian agent were depicted that way, he would probably die chanting 'Vande Mataram', sacrificing his life for his country, at the end of the book - as depicted in countless Indian movies of a certain era. :-) Anyways, the end of the book didn't justify the length of the path that it took to get there, in my humble opinion. But it was good enough for me to want to sample another of the author's offerings.

Hence The Sialkot Saga. There is an element of an ancient powerful secret in here as well. But it is so wafer thin that it gets buried under layers of the plot and its unnecessary twists and turns - only to surface towards the very end of the book, when you are almost sure that the author has forgotten about it. If the book were about the events that took place in India during her partition and post independence, it would have served its purpose of being a good summary for anyone interested in these events. But this isn't a book about history. It's a novel where India's past was supposed to be used as a backdrop. And yet, that backdrop has expanded in size to consume the whole of the narrative. Why the author felt the need to insert the protagonists, Arvind Bagadia and Arbaz Shaikh, in most of these major events, is simply beyond me. A crisper narrative would have achieved the same objective. The plot of brothers getting separated early in life only to be revealed as siblings towards the end has gone beyond being threadbare. :-( I didn't check if the ancient secret mentioned has any basis in history or is merely the product of the author's imagination. But I might just do that one of these rainy days.

The length of both of these books has, however, frustrated me enough not to go for any of the author's books so soon. True, I would like to read The Rozabal Line, Chanakya's Chant and The Krishna Key. Ancient secrets, real or imaginary, have always fascinated me. But alas, the library doesn't have any of the 3 books. :-( And I am not in the mood for reading Private Delhi. Well, currently at least.

The Rooster Bar – John Grisham

I set foot in the library after more than 6 months and immediately realized why I had been feeling sort of lost these past few months. After working my way through the 5-6 magazines (called दिवाळी अंक in Marathi) purchased during Diwali, I was reading only the financial magazines and daily newspapers. Somewhere deep within I wasn’t happy and now I knew why.

The library seemed to have got a whole bunch of new books. I saw the next installment in Amish Tripathi’s Ramayan series. I had read his Scion Of Ikshvaku a couple of years back but suspect that I have forgotten most of the plot (I know it is a take on Ramayana, a story almost all Hindus know by heart. But there are a few twists which I am sure have gone out of my mind by now). This installment seems to be about Princess Sita. I was sorely tempted to reach for it but didn’t because to make sense of it I would have to again go through the first novel in the series. And then repeat the whole exercise when the next installment comes along in a few years. Better to wait and read everything in one go.

But John Grisham has always been a favorite. The plot outlined on the back cover seemed pretty interesting and though one of my new year resolutions is to read as many Marathi books as I possibly can, I decided to start slow. Maybe an English novel or two will do. Hence The Rooster Bar.

It’s probably safe to say that though the plot sounded interesting to begin with, I found it rather unconvincing. Who in their right mind would throw away all the work and toil of past semesters to chuck it all during the last one and head for the sure uncertainty and risk in practicing law without license or degree? I couldn’t find it in my heart to sympathize with Mark, Todd and Zola. The enterprise seemed doomed from the beginning and I wasn’t at all surprised when it all falls apart in the end. Well, sort of. But I also suspect that part of the reason why I felt the novel was such a letdown is because we all are used to the protagonists succeeding in their chosen endeavors – no matter how impossible the task, how insurmountable the difficulties and how hopeless the situation. Zola’s failure to secure any clients, the team’s mishandling of the medical malpractice case and their total ineptness, naivety, not to mention sheer stupidity in making it easy for the FBI to get on their tail made the story too close to real life. If it’s a fiction, it has to have that sliver, however thin, that separates it from reality. That sliver seemed practically non-existent here.

I am not sure if this is the first Grisham novel that I didn’t like. But I sure hope it’s the last.

Don't Just Roll The Dice - Neil Davidson

One of the articles that I read recently contained a reference to this book. So I checked it out. Just 70 pages so easily digestible over a couple of days. And the subject is software pricing.

Davidson begins with a short dose of economics. Nothing complex. Just a few basics like the Demand Curve. The second chapter on Pricing Psychology makes an important point that in order to price your product right you need to be aware of two things - one, what is your product and two, what is its perceived value to the customers. Then it goes on to explain how people perceive values and how that can be influenced. Chapter 3 covers pricing pitfalls like e.g. setting the price too low or too high.

The next chapter is about advanced pricing techniques such as different kinds of versions and how to use them to steer the customers to your intended price point, Bundling, Multi-user as well as Multi-site licenses and free trials. It also has a section on pricing models. The last chapter sort of ties the whole book up with the product pricing checklist. If you are too busy to wade through even 70 pages, just go through this checklist.

In a nutshell, this is a good book to turn to if you are looking for an overview of software pricing as well as a few pointers on how to (and how not to!) go about it. Sure, it contains examples from real world to illustrate concepts but there are no detailed case studies. That said, this would be a good first step in the study of software pricing before turning to bulkier volumes.

P.S. Somewhere in the last chapter, the author says 'It's more useful to fix the problem than to understand why it's broken.' That's the only advice that I found hard to digest.

Immortal - by Krishna UdayaSankar (Spoiler Alert!)

Ashwatthama cannot be counted among my favorite characters from the epic tale of Mahabharata. Sure, he was a great warrior. I won't hold his fighting on the side of Kauravas against him. But his one heinous act of killing Draupadi's sleeping children (he mistook them for Pandavas!) at the end of the war didn't only stain his character for eons to come but also earned him a curse right at the hand of God - the curse to roam this earth for eternity, with the festering wound caused by the ripping of the precious stone out of his forehead. No solace, no peace, no mirth. Who can save one whom God Himself has deserted?

UdayaSankar has a different take on Ashwatthama's tale. He is immortal but not because of some curse. It's an experiment in Alchemy that's caused it, making him an aberration, an anomaly, a freak of nature. His present persona is that of Professor Bharadwaj - a historian who helps private collectors get their hands on obscure, but priceless, pieces of antiquities. Maya, approaches him for one such quest - Nagarjuna's Vajra, an instrument that's supposed to be capable of causing transmutation as well as bestowing immortality. As the legend goes, Nagarjuna had broken up the Vajra into 3 pieces, hiding them in different locations and the details of the same are now lost in the mists of time. Professor Bharadwaj, along with his colleague, embarks on the journey to locate the Vajra but someone else is also on this trail - to make sure that he doesn't succeed.

There cannot be any doubt that the plot has promise. Loads of it. But the problem is that the author has introduced unnecessary complexity at places. One case in point - references to scientists like Issac Newton, Robert Hooke and Niels Bohr and their work towards the end of the book. I really couldn't understand the point of it. The book also leaves a lot of questions unanswered like e.g. if Professor Bharadwaj did finally end up killing Maya why did he let her go earlier? What was he expecting to find in the final place that they visited? I also didn't understand what caused him to turn immortal.

If you are a fan of a fresh take on epics and mythological tales, this book is definitely worth a read. If not, it might leave you with a vague sense of disappointment, and lot of unanswered questions.

Do More Faster - David Cohen & Brad Feld

Just finished reading this book. Basically, it's a series of short advices by mentors and entrepreneurs alike from Techstars - a mentorship-driven startup accelerator firm. Those of you who know me must be wondering what I have got to do with Entrepreneurship. True, the idea of me starting a company sounds pretty hilarious. But maybe I will end up working with one in near future. And in any case, it doesn't hurt to know about things. One never knows when such knowledge may come in handy.

Okay, so the book is divided into 7 parts - Idea & Vision, People, Execution, Product, Fundraising, Legal & Structure and Work-Life Balance (yeah right!). In 'Idea & Vision', we get to read about interesting (and might I say, sometimes counter-intuitive!) suggestions like entrepreneurs should not get too secretive about their ideas (because execution, and not ideas, are important), concentrate on one pain area of the users and treat it well, avoid the temptation of adding too many features at the beginning, iterate often so as to get an early feedback and of course, fail fast.

The 'People' section is rich with gems such as Hire people better than you, Hire slowly but fire quickly, have a co-founder. engage a mentor and build a balanced team. Dharmesh Shah's checklist for co-founders is very informative. I couldn't help but smile at the first item on Greg Gottesman's list for great startup culture - No Politics! :-) But the rest of his list is spot-on.

In 'Execution' section, the advice ranges from the obvious 'Do it faster' & 'Use your head, then trust your gut' to more thought-provoking 'It's Just Data' - which tells startups about how to deal with conflicting information - & 'Process equals Validated Learning' which means knowing so much about your target market and potential customers that you can achieve growth rates that others can only dream about. As far as 'Product' goes, emphasis is on things like getting your product to customers early but with regular updates, focusing only on things that help you make progress and paying attention to key metrics about your customers. It also has one really useful article on what precautions startups should take while dealing with the big companies.

'Fundraising' gives good tips on when to go for fund-raising and when to avoid it. The essays titled 'Beware Of Angel Investors Who Aren't' and 'Get Help With Your Term Sheet' are a must-read. No essay from 'Legal & Structure' section should be missed by startup founders. And essays from 'Work-Life Balance' reinforce what they have always been saying about all work and no play making Jack a dull boy! :-)

In a nutshell, if I ever think of starting a company in this life, I would have a well-thumbed copy of this book somewhere on my desk. :-)

Woman Of God - James Patterson & Maxine Paetro

Frankly, I picked this one up based solely on its plot - which involved Vatican and selection of new Pope. I was hoping for behind-the-scene intrigues and twists as in The Conclave. The book contained neither. That, however, wasn't the source of my disappointment.

What disappointed me greatly was the fact that I couldn't understand what exactly did the author(s) want to convey. That a human being has the ability the commune with God without the help from any clergy or holy men/women? That humans would do well to listen to their inner voice when it comes to their calling in life? That those who work with the poor and downtrodden are the only ones who are doing God's true work? Or that He works in mysterious ways?

So it was with only a half-hearted enthusiasm that I could follow the life of one Brigid Fitzgerald as she worked with the poor of South Sudan on two separate occasions, helped nab a genocidal maniac, got married, lost her husband and baby, married a priest, again lost her husband and ended up starting a revolution of sorts when it came to the matters of the Catholic Church. I couldn't help  but roll my eyes as the warm feeling in heart, the sensation of raindrops drying on skin and gentle breeze indicated that God was trying to say something to Brigid. 'Hey, you left out the white light' I felt like telling the author(s).

But above all, what riled me most was the thought expressed in the novel that God has brought us into this world but we all are responsible for our lives. He cannot intervene. Really? I don't have any problem in being responsible for my life but then I would have much preferred it if God had given me more control over it. And if He had sent me on Earth with a little booklet explaining the rules of the game. And if He had promised not to disrupt the best-laid plans with His neat little tricks. Oh, and BTW, if He expects us to manage our own lives, why do we need to pray to Him?

I guess God, if at all He exists, would do better than take a hands-off approach, if He wants His creation to make it into the next century. As of now, that looks pretty dicey to me.

Lean Software Development: An Agile Toolkit - by Mary & Tom Poppendieck

To put it in a nutshell, this is a book that tells you how to apply Lean principles to software development.


There are 7 of these principles - Eliminate Waste, Amplify Learning, Decide as late as possible, Deliver as fast as possible, Empower The Team, Build Integrity In & See The Whole. There are total 22 tools spread across these principles to help you apply them to software projects.


What struck me first is that the language used is very easy-to-understand. There is almost no jargon. There are plenty of references for further reading. And liberally sprinkled throughout the text are anecdotes and examples from real world - I don't want to call them 'Case Studies' because they are told in a very easy-to-follow manner - that many of us from the software field would surely relate to. You don't have to read this book cover-to-cover. There is plenty to gain even if you select a principle and start reading the relevant sections.


I highly recommend this book for light but useful reading on managing projects. I am sure you would keep referring back to it. I surely am going to.

खलनायक - सदानंद गोखले

खरं तर ह्या लेखकाचं नाव मी ऐकलेलं नाही. पण पुस्तक चाळून पाहिलं तेव्हा इंटरेस्टिंग वाटलं. पुस्तकाची मांडणी तशी चांगली केली आहे. पहिल्या भागात जुन्या काळातील के. एन. सिंग., जीवन अश्या ओळखीच्या आणि याकूब, नायमपल्ली ह्या (निदान मला तरी) थोड्या अनोळखी व्हीलन्सने सुरुवात होते. दुसर्या भागात अमजद खान, प्राण, अमरीश पुरी ह्यासारखे दादा लोक भेटून जातात. तिसर्या भागात विनोद खन्ना, शत्रुघ्न सिन्हा आणि नाना पाटेकर ह्या नायक असून खलनायकाची भूमिका केलेल्या नटांबद्दल माहिती मिळते. ह्या गटात नानाला कोंबायचं प्रयोजन मला कळलं नाही. पण बहुतेक तो दुसर्या कुठल्या गटात बसत नसल्याने त्याला इथे समाविष्ट केलं असावं.


चौथा भाग वेगळा का केला हेही समजलं नाही. ह्यात अजित, प्रेम चोप्रा, गुलशन ग्रोव्हर असे वेगवेगळ्या काळातले व्हीलन्स एकत्र आणलेत पण शीर्षक दिलंय 'व्हिलन बाय प्रोफेशन'. म्हणजे काय? सगळे प्रोफेशनल व्हीलन्सच आहेत की. तीच गत पाचव्या आणि सहाव्या भागाची. पाचव्यात 'समथिंग स्पेशल' ह्या नावाखाली अशोक कुमार, तरुण बोस, रेहमान, शशी कपूर आणि प्रेमनाथ ह्या सगळ्यांची एकत्र मोट बांधली आहे. तर सहाव्यात शक्ती कपूर, अन्वर हुसेन, मनोज बाजपेयी असे ५-६ व्हिलन्स भेटतात. पहिल्या तीन भागातल्या स्वच्छ वर्गीकरणाचा इथे साफ फज्जा उडालेला दिसतो.


सातवा भाग थोडाफार रुळावर आलाय. ह्यात गाण्यातून व्यक्त झालेली खलनायकी, डाकू, दरोडेखोर असे विषय आहेत. आठवा भाग - हॉलीवूडच्या खलनायकांवरचा - फारच संक्षिप्त झालाय. नवव्या भागात मराठीतले खलनायक आहेत. डॉ. श्रीराम लागू, सदाशिव अमरापूरकर आणि निळू फुले ह्यांच्याबद्दल विस्ताराने माहिती असली तरी राजशेखर, दादा साळवी ह्यांच्यासारख्या नटांचा, शशिकला, इंदिरा चिटणीस ह्या मराठी खलनायिकांचा उल्लेख नाही, जुन्या ऐतिहासिक, पौराणिक किंवा ग्रामीण विषयांवर आधारित चित्रपटातल्या खलनायकांबद्दल काहीच माहिती नाही हे खटकतं.


तसंच ह्या सगळ्या वर्गीकरणाच्या गडबडीत मनमोहन, मेकमोहन, देव कुमार, सुजितकुमार, रझा मुराद, शेट्टी असे अनेक खलनायक विसरले गेलेत.

शेवटला भाग मात्र छान जमलाय. ह्यात ललिता पवार, शशिकला, नादिरा, बिंदू, हेलन ह्यासारख्या गाजलेल्या आणि प्रणोती घोषसारख्या एकाच चित्रपटात झळकलेल्या खलनायिकांबद्दल चांगली माहिती मिळते. मात्र अरुणा इराणी, शम्मी, मनोरमा ह्यांचा उल्लेख राहून गेलाय.


प्रत्येक खलनायक आणि खलनायिकेबद्दलचं प्रकरण मात्र खूप विस्कळीत झालंय. प्रकरणाची सुरुवात कधी त्यांचा ह्या क्षेत्रात प्रवेश कसा झाला ह्याच्या माहितीने, कधी त्यांच्या चित्रपटाच्या यादीने तर कधी एखाद्या किश्श्याने होते. त्यापेक्षा आधी त्यांचा प्रवेशआणि मग त्यांचे चित्रपट त्यातल्या खास किस्से आणि वैशिष्ट्यासह अशी मांडणी असती तर मजकूर अधिक वाचनीय झाला असता. काही लेखात अनवधानाने चित्रपटातील रहस्य उलगडलं गेलंय – उदा. गुमराह (अशोक कुमार) आणि गुप्त (काजोल). तर काही ठिकाणी तपशिलाच्या चुका झाल्या आहेत – उदा. लावारिस मध्ये अमिताभ बच्चनची आईआणि प्रेयसी दोघींच्या नावाचा उल्लेख 'मोहिनी' असा आहे. तर 'आरती' चित्रपटाच्या बाबतीत शशिकलाचा उल्लेख नायिकेची नणंद आणि जाऊ असा झालाय.


ह्या पुस्तकातून बरीच माहिती मिळत असली तरी ते अधिक वाचनीय करता आलं असतं एव्हढं नक्की.


ता. क. ‘राजकुमार आणि रेहमान ह्यांची "वक्त" मधली संवादातली जुगलबंदी आणि दोघांचं टायमिंग म्हणजे उच्च कोटीच्या अभिनयाचा आविष्कार होता' हे वाक्य वाचून भरपूर करमणूक झाली. राजकुमार अभिनय करायचा हि ब्रेकिंग न्यूज आहे :-)

Into The Water - Paula Hawkins

At first, it was difficult to remember all characters - they made fast appearances within first few pages. And there were quite a lot of them. Jules's (not Julia!) quiet little world is shaken to the core when she gets news that her elder sister Danielle (Nel!), who she has been estranged with since years, has committed suicide and that she will have to take care of Lena, Nel's teenage daughter, who hates her for always ignoring her mother.

Then there are the residents of Beckford. DI Sean Townsend is a capable officer but there is a shadow there somewhere of some tragedy - recent or past, it is hard to figure out. His wife, Helen, is rather plain-looking but there is steel beneath that soft exterior. Sean's dad Patrick is well-respected in the community but the town's psychic (I forget her name!) cannot help but suspect that he had something to do with the death of his wife. Then there is Katie, Lena's 15-year old dear friend who had ended her life but no one knows why. Her younger brother Josh is evidently keeping some secret. Her mother is trying her best to cope with her grief but blames Nel for Katie's death. Mark Henderson is a handsome teacher - perhaps a tad too handsome for the 'little town of Beckford'. There is a police officer who is assisting Sean in the investigation of Nel's death.

And surrounding all this are two structures. One of them is man-made. The other was fashioned by Nature. Wards' Cottage has a bloody history associated with it - Annie killed her husband there and then jumped into the pool. Ah yes, The Drowning Pool. A place where countless women, through centuries, have reportedly ended their miserable sad lives. But Nel had been sure that the pool was a convenient place to get rid of women who had become 'troublesome' for someone or other. Did her conviction made someone get rid of her? Or did she commit suicide? Was Jules justified in hating her all these years?

We get some answers and some, we don't. Of course, the author tells her whether Nel killed herself or was murdered by someone. She tells us why Jules hated her for almost all her life. She also tells us about why Annie killed her husband, why Libbie Setton was drowned in the pool and how Sean's mom died. But she doesn't tell us about how Jeanie died. She doesn't tell us about how Patrick ended up with Nel's locket, though we can make an educated guess. We are kept wondering about how town's psychic knows things that even the cops are unaware about. And about what exactly is the relation between Patrick and Helen. And about what happend to Henderson. The twist in the tale sounds lame and artificial, as if the author thought of it at the very last minute.

Needless to say, the book left me with a sense of being cheated by the author :-(

97 Things Every Programmer Should Know

To be frank, I was looking for '97 Things Every Architect Should Know' when I came across the above title instead. Intrigued, I read on.

And was glad that I did. Ranging from the delightful 'Learn To Say "Hello World" -' about letting go of your IDE and using the command line tools - to the quirky 'Let Your Project Speak For Itself' - about using an extreme feedback device to publicizing project metrics - to the arcane (at least to my Java ears!) 'The Linker Is Not A Magical Program', this 188 page book is packed with little gems that will go a long way in improving not only your projects but also how you do your work. And they are a joy to read.

I highly recommend getting a copy for the developers in your team. And while you are at it, do take some time to go through it yourself.

P.S. Wonder why they couldn't make it a 100 things.

Patterns Of Software - Richard Gabriel

At the beginning of this year, a friend had forwarded a list of things to do this year. One of them was 'Read a difficult book'. I guess I can confidently put a check against this one - I just finished reading 'Patterns Of Software' by Richard Gabriel. To be accurate, it's not actually a book. Rather, it is a collection of essays that appeared in the Journal Of Object-Oriented Programming, somewhere in the distant 90s. Though many of them talk about how 'Patterns Of Architecture' popularized by architect Christopher Alexander apply to the world of software, there are others that talk about the size of computer languages, their history, productivity etc.

To be fair, I hadn't expected to grasp 100% of the material. And some parts of many chapters simply sounded too  abstruse. But the article that totally stumped me was 'The Bead Games, Rugs and Beauty'. I tried to make sense of it, I really did. But my grey matter was just not upto the task. Much as I like leaving things unfinished, I had to abandon reading the chapter. Must say that this chapter is mainly responsible for my completing the 'Read a difficult book' part of this year's to-do list. :-)

And I was thinking that the honor would go to Stephen Hawking's 'A Brief History Of Time' :-)

Crossing The Chasm – Geoffrey Moore

It’s a dated book. I will grant you that. It was originally written in 1991 and even the revised edition is from 1998. But it is mere 174 pages and to be frank, I don’t reach out for marketing books in my sane frame of mind :-)

So what’s the chasm? Basically, it has to do with the technology adoption life cycle with its 5 distinct phases – Innovators, Early Adopters, Early Majority, Late Majority and Laggards. The chasm exists between Early Adopters and Early Majority and so the book talks about what needs to be done to make sure that the product travels smoothly from Early Adopters to Early Majority – without ever losing momentum, and thus market share, profitability etc. Etc. The author also makes it clear that the efforts have to be made by all parts of the organization and not just the marketing folks. There are many reasons for the existence of this chasm but chief among them is the fact that the Early Majority is seeking maximum discontinuity from the old ways of doing things whereas the Early Adopters are looking to minimize it. It also doesn’t help that while the Early Majority can  live with a few bugs, the Early Adopters are far less tolerant of them. The net effect is that Early Adopters cannot be referrals for Early Majority. Hence the chasm. That basically is the gist of the first chapter.

In the second chapter, the author sets about explaining how to close this chasm. The definition of a market consists of the familiar terms – customers, their need and the product that promises to fulfill it. The addition here is the reference that the customers seek from each other before making a buying decision when it comes to high-tech products. What follows is a description of salient characteristics of each phase of the technology adoption life cycle, the gotchas and must-dos of marketing to them.

The third chapter starts by talking about the unsavory characters - such as ruthless competitors & predatory investors -  that seem to inhabit this chasm and emphasizes the need to select a target niche market as the first point of targeted attack on the way to heading into the major market. The analogy of Allied Invasion of Normandy on D-Day fits it like a glove. Though I don't know the ABC of marketing, the scenarios described in this chapter are so logical that I found myself nodding in understanding. There is also an interesting section about 4 companies that seem to have navigated this chasm successfully. Unfortunately, the chapter doesn't offer any tips about how to effectively deal with the unsavory characters that are talked about at the beginning.

The 4th chapter is about how to make your decisions about the high-risk low-data market that's going to be your springboard into the wider market. And the interesting subject of Target Customer Characterization. The fifth chapter deals with how to shape the market for your company's whole product offering. The main poitnt that the author makes is that while the early market (consisting of innovators and early adopters) can get by without the Whole Product, the other side of the chasm needs it.

Chapter 6 is about fighting it out with the entrenched competitor and forcing him or her out of the target market segment. Oh, and creating competition if it doesn't exist. Sounds counter-intuitive? It sure does. But then you got to read the chapter to know what the author has in mind. I found the section on 'Positioning' a bit hard-to-digest but that could be because I am not the marketing type.

The last chapter tackles distribution and pricing i.e. customer-oriented distribution and distribution-oriented pricing. I don't know for sure but I suspect that this is perhaps the most dated chapter of this book because the Internet has come a long way from what it was in the 90s.

P. S. It was amusing to read the following about neural networks - the software has shown little commercial success because there has not yet emerged a unique and compelling application that would drive its acceptance over other, more established alternatives. Oh, and also the following one - Today, however, AI has been relegated to the trash heap. :-)

चंदेरी दुनियेत – लीला चिटणीस

लीला चिटणीस म्हटलं की माझ्या डोळ्यांसमोर येते ती परिस्थितीने गांजलेली, नवर्याचा मृत्यू झाल्याने किंवा त्याने सोडून दिल्याने मुलांना एकटीने कष्ट करून वाढवणारी, त्यांच्यावर चांगले संस्कार करणारी,पण सदोदित रडणारी आजारी आई. ह्या अभिनेत्रीने कधीकाळी नायिकेच्या भूमिका केल्या होत्या, नाटकातून कामं केली होती हे वाचून मला बराच धक्का बसला. अर्थात अशोककुमारचा 'महल' पाहिल्याची चूक केल्याने कंगन. बंधन आणि झुला हे ते तिन्ही चित्रपट कधी बघायची वेळ आलीच तर जवळ एक बामची बाटली घेऊन बसावं लागणार ह्याची खात्री आहे :-) पण तरुणपणीच्या लीलाबाई दिसतात तरी कश्या आणि अभिनय कसा करतात ते पाह्यची मोठी उत्सुकता मात्र हे पुस्तक वाचून लागली आहे. तेव्हा ह्यातला एखादा तरी चित्रपट बघणं 'बनता है'.

हे पुस्तक फक्त त्यांच्या आयुष्याची कथा नाहीये तर त्यांची चित्रपटसृष्टीतली कारकीर्द, त्यात त्यांना आलेले अनुभव, त्यांचं व्यक्तिगत जीवन, स्वतंत्र होण्याआधीच्या भारतातलं जीवन, त्यावेळच्या राजकीय आणि सामाजिक घडामोडी, तेव्हाच्या काळात बनणारे चित्रपट, त्यात काम करणारे दिग्दर्शक, निर्माते, नायक, नायिका, चरित्र अभिनेते, एक्स्ट्रॉज, गीतकार, संगीतकार, केमेरामन, बाकी तंत्रज्ञ, तेव्हाची टेक्नोलॉजी, शुटींगमध्ये येणाऱ्या अडचणी, त्यावर केलेली मात, तेव्हाच्या चित्रनिर्मिती संस्था (प्रभात, बॉम्बे Talkies) , चित्रपटांचं वितरण, प्रदर्शन असा एक विस्तृत पट त्यातूनआपल्यासमोर उलगडतो. उदा. त्या काळातले चित्रपट पाहताना मध्येमध्ये कंटिन्यूइटीची गोची झालेली आढळते ते पाहून हसू येतं. पण ही कंटिन्यूइटी सांभाळण्याचं काम किती जिकिरीचं आहे ते हे पुस्तक वाचून ध्यानात येतं. एक चित्रपट, मग तो कितीही टुकार का असेना, बनवायचा तर किती लोकांचे श्रम लागतात ते वाचून तर भारतात इतके चित्रपट तेव्हा बनत होते हयाचंच आश्चर्य वाटतं.

लीलाबाईच्या व्यक्तिगत जीवनाबद्दल बोलायचं झालं तर नवर्याच्या देशप्रेमाने भारून गेलेल्या कामात स्वत:ला झोकून देणाऱ्या साध्या गृहिणीकडून एक प्रथितयश अभिनेत्री, घटस्फोटिता ते लिव्ह-इन रिलेशनशीप मध्ये रहाणार्या स्त्रीपर्यतचा प्रवास आश्चर्यकारक आहे. अगदी 'हीच का ती स्त्री' असं वाटण्याइतपत. खरं तर हंसाबाई काय किंवा लीलाबाई काय, पण ह्या चित्रपटसृष्टीच्या मोहमयी दुनियेत वावरणाऱ्या लोकांचे संसार सुखाचे का होत नाहीत हे कोडं आहे.

तरी एक प्रश्न पडतोच. हिंदी चित्रपटसृष्टीमध्ये खास स्त्रीप्रधान भूमिका बनायला आत्ता आत्ता सुरुवात झाली आहे. तेव्हाच्या काळात तर त्या असणं अशक्यच. त्यामुळे एक ठराविक वय ओलांडल्यानंतर स्त्री अभिनेत्रीला आई/सासू अश्याच भूमिका करणं क्रमप्राप्त होतं. पण त्याच त्याच चाकोरीतल्या गरीब आईच्या भूमिका करताना लीलाबाईमधल्या अभिनेत्रीची काय प्रतिक्रिया होती?

केवळ एका अभिनेत्रीच्या व्यक्तिगत जीवनाबद्दल नव्हे तर ३० ते ७० सालातल्या हिंदी चित्रपटसृष्टीबद्दल जाणून घ्यायची उत्सुकता असलेल्यांनी नक्कीच वाचावं असं हे आत्मचरित्र आहे.