A Man Called Ove - Fredrik Backman

The Lives Of A Cell - Lewis Thomas

Born A Crime - Trevor Noah

One Part Woman - Perumal Murugan

What Money Can't Buy: The Moral Limit Of Markets - Michael Sandel

Jon R. Katzenbach and Douglas K. Smith. The Wisdom of Team: Creating the High-Performance Organization.

The Toyota Way - Jeffrey Liker

Johanna Rothman. Hiring the Best Knowledge Workers, Techies, and Nerds: The Secrets and Science of Hiring Technical People.

Johanna Rothman. Manage It!: Your Guide to Modern Pragmatic Project Management. The Pragmatic Programmers,

Robert C. Solomon and Fernando Flores. Building Trust in Business, Politics, Relationships, and Life.

Keith Sawyer. Group Genius: The Creative Power of Collaboration.

Preston G. Smith and Donald G. Reinertson. Developing Products in Half the Time: New Rules, New Tools

R. Brian Stanfield, ed. The Art of Focused Conversation, 100 Ways to access Group Wisdom in the Workplace

Steve Tockey. Return on Software: Maximizing the Return on Your Software Investment.

Allen C. Ward. Lean Product and Process Development

Gerald M. Weinberg. Psychology of Computer Programming

Gerald M. Weinberg. Weinberg On Writing: The Fieldstone Method

James P. Womack and Daniel T. Jones. Lean Thinking

Tim Mackinnon, Steve Freeman, and Philip Craig. Endo-testing: Unit testing with mock objects.

Giancarlo Succi and Michele Marchesi, Extreme Programming Examined

Pragmatic Programmers. Pragmatic Automation

Jeremy Epstein - It’s ALL on the Blog, DON’T Buy the Book

Andrew McAfee and Erik Brynjolfsson Machine, Platform, Crowd 

The Attention Merchants, Tim Wu

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.

Goodbye Flora

Over the years I have seen many restaurants close shop and I do miss some of them from time to time. Komla's in High Street Phoenix for example. They used to have such nice South Indian thali. When they closed down, I was hoping to run across an outlet in some mall or other but then a friend informed me that they had winded their operations across India. That was sad. Mah Jong in Khar was another of my favorites. They used to make a mean crispy threaded chicken. Spaghetti Kitchen closed down at Phoenix and so did Copper Chimney. The silver lining is that there is one outlet of Copper Chimney at Kala Ghoda. Just love their Biryani, Kebabs and Mint Chutney. I also miss an outlet serving Maharashtrian Thali at Shivaji Park.

And then there was Flora. It was this restaurant that gave me my first taste of Chinese food during my childhood years. The chef back then used to dish out utterly delectable fare such as dry chilli chicken, chicken fried rice, whit prawns and crab corn soup. A couple of years ago we had trouped back to Flora but the menu had changed completely over the years. Whatever we ordered didn't quite have the same quality as the food dished out there in the 80s. I know it is foolish to expect the same taste after a gap of about 20 or so years. But I have been searching for the same taste ever since. Whenever I see Chilli Chicken (Dry) on any menu, I order it - only to get disappointed every single time. Only the chilli chicken served at China Bistro buffet came anywhere close to the one that used to be served at Flora. I also tried my hand at making crab corn soup at home but obviously couldn't get the same taste. I can't remember what the prawn dish was called but still vividly remember the big white prawns - perfectly cooked and perfectly seasoned. I am not a big fan of seafood - except for pomfrets. So the fact that I am still drooling over their prawn dish after decades is a testimony to the cooking prowess of their chef from the 80s.

I sometimes wonder if I would see Time Machine being invented in my lifetime. If I do and it becomes affordable enough for common man's use (a long shot!), I have a list of places and periods to go to. Most of them are moments in India's and world's history. But a trip to my maternal grandparents' house sits almost at the top. Now a visit to the Flora of the 80s has got added to it.

Thank You Flora!

Most of the ads these days make you wonder what in the world was the person who conceived of them thinking at that time. But once in a while you come across some ad that makes you want to applaud its creator. That's especially true if you appreciate the ad despite knowing that what is being shown isn't going to happen in real life.

I watched one such ad last weekend - it was about organ donation. The first shot is of a mother-son duo celebrating the mother's birthday. Happy Moments! Then the narrative moves forward by a whole year. It's the same date but now the mother is alone. The son has passed away. As the mother is looking on at his photo forlornly the doorbell rings. When she opens the door, there is no one outside. Just when she is about to close it she notices a box on the threshold. She brings the box inside and on opening finds a huge cake inside with the words 'Happy Birthday Mother' written on it. She is puzzled. The cake is delivered the next year and the year after that but on both occasions the sad mother is unable to discover who has sent it.

The year following that, the cake isn't delivered though it is pretty late in the day. And then we see the camera approaching the house. Someone places the cake outside and rings the bell. As the woman turns to go, she sees the mother in front of her. The woman is unable to hide her emotions and explains to the mother that if her son were alive he would have done the same for her. The mother places her hand where the woman's heart - which quite obviously was donated by her diseased son - is. The background song expresses the son's feelings that the body, the face is different but the heart has managed to come back to his mother.

Now we all know that the organ donor's and receiver's identities aren't supposed to be revealed to each other so what is shown in the ad cannot happen in real life. But in this country where people die waiting for a matching organ, it drives home the importance of organ donation beautifully. Knowing the Indians' soft spot for moms and anything to do with them, it perfectly draws at their heart-strings to make the point that your loved ones go on living when their organs give life to someone else.

Panch Pulla & Satdhara, Dalhousie

To put it bluntly, if you have seen any waterfalls (and you must have unless this is your very first trip!) and are pressed for time, do give this place a miss by all means. You will avoid getting accosted by dubious people trying to sell Saffron (if you are a female) or Shilajeet (if you are a male). Where is gender equality when you need some, I say? :-) Then there are quite a few steps to climb- which can be quite daunting for senior citizens in your group, and a few unfit members. If you brave all this to reach the fall, it isn't gigantic.

Of course, if you want to try your hand at some adventure sport, it's a different matter altogether. We did see a brave soul zipping by on an overhead rope every couple of minutes - but I suspect he was one of the men operating the equipment rather than any tourist. There are a couple of rope bridges, if you want to experience the thrill of walking dangerously. I didn't - because I come from Mumbai where BMC provides that thrill for free every day with potholes in the roads, closed pavements owing to metro work and traffic that obeys no rules. When the nearby shopkeepers asked me to take a look at their shawls, I really had to suppress the urge to tell them not to waste their time on me because unless there is a severe climate change (as in Mother Earth thumbing her nose at the US Prez!) I am unlikely to need shawls or any other winter gear in the hotter-than-hell city of Mumbai!

On a positive note, the tea vendor sells a good enough cuppa, if you are missing your daily fix.

As far as Satdhara goes, I am still wondering about its name. There is irony there somewhere, I am sure. It was just a trickle and our driver mumbled something about some mineral deposits as he stopped the car in front of it for all of 2 minutes. Even Maggi would take longer to get ready!

So do yourself a favor and drop this from place your program, if you are short on time.

P.S. This place also has a monument in memory of Sardar Ajit Singh. Nothing more than a statue and a plaque, as you can see in the photo above. Nothing is mentioned about his life. I don't know about you, but I don't remember reading about him in history books. Sad, but true. The government should provide some details of his life rather than expecting us to Google about him!

गुजर जाते है खूबसूरत लम्हे यूही मुसाफिरों की तरह
यादें वही खड़ी रह जाती है रुके रास्तों की तरह

(Forwarded)