Skip to Content
<p>DISCLAIMER: THE CONTENT OF THIS BLOG ISNT ANYTHING WHICH SAP ADVOCATES.  This is my personal view.</p><p>My interest in Game Theory emerged while I was in university. It started with a puzzle and hasnt ended yet. I have been using Game Theory strategies in practical scenarios and have been successful till now. </p><p>In this blog, I would like to highlight one of the those strategies which has really helped me in coding(programming). The strategy is well known “Tit for Tat”. I am copying few lines verbatim here from Wikipedia. For more information on the link, please visit the link given above.</p><p><From Wikipedia></p><p>Tit for tat is a highly effective strategy in game thoery for the iterated prisoner’s dilemma. It was first introduced by Anatol in Robert Axelrod’s’s two tournaments, held around 1980.

This strategy is dependent on four conditions that has allowed it to become the most prevalent strategy for the Prisoner’s Dilemma:

  • If provoked, the agent will retaliate
  • The agent must have a good chance of competing against the opponent more than once.

In the last condition, the definition of “good chance” depends on the payoff matrix of the prisoner’s dilemma. The important thing is that the competition continues long enough for repeated punishment and forgiveness to generate a long-term payoff higher than the possible loss from cooperating initially.

So you must be wondering how can this strategy be used while coding?

I find that most of the programmers write the best code they can write from start of implementation phase only. They have no bottlenecks in their code, have beautiful UI etc. But I feel this strategy can be disadvantageous in many scenarios:

1. Change in Requirement:  For example: The new requirement is to replace ALV grid with ALV tree. The programmer has to now re-code everything. Did he do any benefit to himself or project by writing perfect code at first stance only? Did he benefit anything by optimizing ALV Grid look and feel at first stance only? Did he benefit anything by writing those perfect select queries just to improve those 10 micro seconds?

2. We later realise that the design is flawed and hence most of the coding isnt needed anymore. I ask same questions here.

3 Most of the end users/customers/clients arent even bothered if you improve the performance of the application by 10 micro seconds? Why did you waste that one day of yours to write that perfect query?

4. Etc

So can Tit for tat help us? 

Now, I consider code reviewers, clients, checkman etc as my opponents in the game. Now the first guideline of Tit for tat is: Never defect first. This means I will write the appropriate(not the best) code when I code for the first time. Appropriate code is code where I follow only standard guidelines like:

1. No literals.

2. Objects Naming Guidelines

3. Priority one errors of Checkman

4 Standard UI

5. No major performance issue

6 Etc

The second point of this strategy advocates to retaliate only when you are provoked. So you modify code(from appropriate to better code or “best” code) only when your opponents ask you. Exemplyfying: If your client says: “mister, I think the UI of ALV is quite complicated. Can you please remove few columns from it”? Your reply” Sure sir, this would not even take 15 mins”.. Here, I pity on the programmer who wasted his one man day just to forecast which all columns in ALV isnt required by end user. Please note that I am not using exact conotation of retiliate here.

The third point in Tit of tat strategy is pretty straight forward. It is just another way of saying:

1. Please make best of design so that modifications(required) are easy to make.

Just to conclude, tit for tat is one such strategy which can be used in various scenarios. For example, Project Management. How should you tackle your client or customer? The answer lies in “tit of tat” and this time take exact meaning of “retaliate”. You defect once for each of his defects. For more information as in how to defect, please see the Wikipedia link above. It is proved statistically that in a long run, this strategy will be fruitful in case mentioned above. Read http://dcg.ethz.ch/publications/p2p07.pdf  for more information on Tit for tat.

 

 

 

 

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Puru,

    This is definitely an interesting approach to development.  I think that most experienced developer’s probably do this in some way or another.  But here are some comments/questions:

    1.  If you apply this to all development, are you basically assuming that all “specs” you received are flawed and you will have to change anyway?

    2.  You should never underestimate performance.  If you do not have access or understanding to the live data at a customer, those 10 microseconds you shave off in a development environment, could mean hours in a production situation.  For complex developments processing lots of data, it always helps to give some thought to performance optimization up front.  Especially if you have past experiences with the data.

    3.  First impressions are important.  At a minimum you need to meet your first set of requirements.  If you deliver a product to a customer that doesn’t meet what they requested, then you are immediately starting off on a bad note.  Regardless of whether they change their mind.

    4.  Spend more time up front with your customers before coding so that the back an forth in the development cycle can be minimized.

    I have been working at the same company for over 7 years and these techniques work quite well also.

    Best Regards,

    Chris H.

    (0) 

Leave a Reply