Category Archives: Programming

In case you thought English didn’t matter since you are only a Java developer..

Just in case you thought English didn’t matter for you, because you are only a Java developer, think again..

// These two Java comments mean entirely different things:

// First determines whether this enrollment application is valid or not.
// First determine whether this enrollment application is valid or not

Monty Hall Problem – Simulation using Python

Had too much time between my flights at Frankfurt, and the old “Find and Win the Elephant/Car Behind 3 Doors” (Monty Hall problem) puzzle is easily the simplest psychology/probability/Math puzzle that bothers people. The puzzle, commonly stated is as follows:

You are a contestant on a game show, where the prize is a Mercedes Benz. You are shown 3 unmarked doors, one of which is the door to the Benz and the other 2 doors lead to nothing (or goats). You can pick a door, and if you pick the right door, you can drive away with a new Benz. Most of us can quickly agree that the probability of winning the Benz is 1/3. (The interesting variation comes next.)

The setup is the same – you are still a contestant, trying to win the Benz, and there are still 3 unmarked doors. However, in this case, the game show host, who knows the door that has the car, is trying to help you. When you pick a door, the game show host flings open one of the two doors that you did not select, and that door (as you can observe after he flings it open) does NOT lead to the car. Then, he gives you a chance to reevaluate your choice – you can keep the door that you originally selected, or to switch to the other unopened door.

The question is: Should you switch?

The subtext here is that door that you selected, has the probability of being the right door of 1/3, and of not being the right door of 2/3. If you did not select the right door initially, when you switch, you will have the right door. If you selected the right door initially, when you switch, you will have a wrong door. So, if you do switch, the probability of you getting to the right door becomes 2/3, and there is a probability of 1/3 that you leave your good door and go to a wrong door. You can choose to look at it very many different ways, and come up with many good arguments, and you can convince yourself one way or the other.

There are many answers to this problem, and one of which, which happens to be the CORRECT one is, that Yes, you should ALWAYS switch. The probability of you winning the Benz if you switch, is indeed 2/3. The probability of you winning the Benz, if you do not switch remains a rather uninteresting 1/3.

If you have had enough of the arguments, you can look at this simple Monte Carlo simulation, and observe the results yourself. Of course, no reason to trust the results without looking at the code, so please feel free to download the source code here. The simulation models two contestants – contestant 1 who always switches, and contestant 2 who never switches and sticks with the original choice.

>>> =================== RESTART ======================
Total number of times run: 100000
Win count when switching the choice: 66613
Win count when not switching the choice: 33267
>>> =================== RESTART ======================
Total number of times run: 1000000
Win count when switching the choice: 666085
Win count when not switching the choice: 333498
>>> =================== RESTART ======================
Total number of times run: 10000000
Win count when switching the choice: 6665600
Win count when not switching the choice: 3329991

It is a Monte Carlo simulation, so you can run it, and you can observe different results each time due to randomization. I do not have Python experience, so I used Python in this example so I could learn it a bit as well. If you have a different programming language that you think I should keep in mind for some other simulation, let me know.

Code Reviewers’ Pet Peeves

As a code reviewer, certain things tend to bother you more than other things.  Here is the list of 3 things that bother the @*(# out of me.

  • Using code as the revision control system:  Developers tend to comment out code, not delete it.  Call it pride of authorship or something else, but it is difficult to delete that excellent, eloquent, functional piece of code that was relevant before your product/project manager decided to change the requirements completely (and completely out of blue, barely x hours after lauding your excellent work!).  The main justification that the developers tend to give is, “Well, what if we want to add that feature back?”  Well, Joe, no, we are never going to bring that feature back!  Never.  Never, ever.  Because we never change our mind.  But just in the slimmest possible lemon peel of a chance that we do bring that feature back, then we will use the RCS to go hunt for that piece of code, or better, you will redo it from scratch!  You wrote such good code the first time around, that I just shudder in awe of the future code that you will write when you have already written that once.  So, for now, stop using code as your RCS, be brave and delete the code.  If we have to give Developer Medals of Honor (DMoH), then, that should be awarded to the brave developers who have written something fabulous and deleted it from their code when requirements changed, thus relegating that phenomenal piece of code to the deathly hollows of the RCS, and done it without evincing pain.
  • Using naming conventions that are beyond wrong: This one causes no visible problems, other than sometimes befuddled customers or higgledy-piggledy users who are confused that the browser bar is showing “AddInvoice.jsp” or something similar, when they were clearly trying to edit an existing invoice.  Horror of horrors!  The customers are just not adept at recreating the thought process of the developer Alice when she was creating the page the very first time, before the first invoice existed at all!  So, Alice conveniently called it the AddInvoice page, and since she is a good developer who follows the reuse principle, Alice decided to reuse the same page for editing an invoice.  Alice, imaginative as she is, did not consider the possibility that a glasses, jeans/t-shirt wearing user would actually notice the URL when using a part of the application.  Clearly, there is no shortage of horror movies in the software world.
  • Using single liner if else blocks: This one is the easiest of the problems to fix.  Just make this a hall of shame qualifier in your team (or a compiler error in your IDE settings).

    No one should write if else logic that does not use curly braces to wrap the pieces of logic that go inside the if and the else blocks.  This really is just a code format issue, but the number of times that I have seen this cause sudden bugs to appear in the version X.0.1 when version X.0 seemed to run absolutely fine is far too many to let this go by.  Too many times, a developer will add a log statement to the first line of the else block, entirely changing the meaning of the block.  This one should be considered the one-liner joke equivalent of the software comedy genre.

Log Viewers, Tails, Chainsaws and 97 Other Reasons Developers Fight with Managers

When I worked with IBM for a navy project, my boss introduced me to the beauty of Chainsaw – a log viewer that ships with log4j.   In so many words “It is called Chainsaw, because it cuts logs to size”, he said with a smirk.  Tech managers have bad sense of humor, but anyway I didn’t want to tell him that I didn’t know what log4j meant as that would have made me sound dumb.  So, I picked up using log4j, and right from get go, really liked it.  Coupled with log4j, chainsaw is a big productivity booster, although you can also use chainsaw with JDK logging.

Logging and log viewers can have a significant impact on developers’ productivity, so the item #7 that I usually cover in the Top 10 Activities that Affect our Productivity is usually about log viewers.  There are of course, a few alternatives to chainsaw, but tail+grep isn’t one of them.  Tail+grep combination is used so frequently simply because developers don’t like being told they something can’t be done using grep.  Developers are, generally speaking, gritty people.  They are there because they like challenges, are knowledgeable and may be opinionated.  Best way of bonding with them is by ranting off against evil companies.  It is sometimes difficult to teach them something new, because hey, they have this really cool other software that not only does what you want it to do, it also makes great foam while playing chess during its spare cycles.  And not onllogy that, you can actually do anything with it.

The problem isn’t really with developers –  it is broader; developers get caught in this solely due to bloggers blogging about developers.  At a more basic level, this problem exists in any form of marketing and is succinctly known as the advertising rule of 7.  Whether the empirical number 7 is correct or incorrect, the notion that sales happens after multiple touch points is hardly debatable.

So, if you have never heard about chainsaw before, you can start counting this as the first touch point. 6 more to go, and I think you will start using it.

[Update: See Scott’s comment below and checkout the awesome new version out.]