Elevating DevOps: A Journey from novice to Master craftsman

 In the dynamic world of DevOps, the gap between theory and practice can sometimes seem as vast as space itself. Reflecting on my journey through countless interviews with DevOps engineers, a pattern emerges: a disconnect between claimed experience and practical knowledge. It's a concerning trend that sees the essence of DevOps, a craft of precision and innovation, being diluted by superficial engagement.

Rewind to the days before DevOps became the industry buzzword. I was at the helm of creating a comprehensive DevOps platform for Geometric Ltd., integrating both commercial and open-source tools. This experience was more than just 'clicking buttons'; it was about architecting a seamless workflow that propelled projects forward.

For those aspiring to master DevOps, here's a distilled essence of my experience:

1. Begin with the roots. Watch John Allspaw and Paul Hammond's seminal presentation at the Velocity 2009 conference. Let it be your DevOps genesis, and absorb its insights multiple times.
2. Dive deep into Version Control Systems (VCS). Whether it's Git, Mercurial, or Subversion, understanding the intricacies of VCS is non-negotiable. They are the backbone of any robust DevOps strategy.
3. Ensure everything is traceable. From source code to CI/CD configurations, every element should be version-controlled, allowing you to pinpoint changes with precision.
4. Immerse yourself in the wisdom of pioneers. My recommended reads include 'Release It' by Michael Nygard, 'The Phoenix Project' by Gene Kim, and 'Accelerate' by Gene Kim and Jez Humble.
5. Learn from the best. Study the engineering blogs of tech giants like Netflix, Google, and Facebook, Uber to stay abreast of cutting-edge practices.

DevOps is not just a role; it's a mindset of continuous improvement and relentless pursuit of excellence. Let's commit to upholding the true spirit of DevOps and nurturing the next generation of software craftsmen. 

Posted on LinkedIn  https://www.linkedin.com/posts/activity-7215942686271238144-7XjI

Awake Proning - ऑक्सिजनची पातळी कमी असल्यास करण्याचे प्रथमोपचार

 एंब्युलंसला किंवा पेशंटला हॉस्पीटलला न्यायला वेळ लागत असेल आणि पेशंटचीऑक्सिजनची पातळी कमी होत असेल तर अशावेळी करण्याचे प्रथमोपचार

Awake Proning

Sane Branch Management of Version Control Systems for Teams

[NOTE : This is still a 'draft', please point out mistakes and suggest changes/improvements]
Some time back Nagaraj Mali asked a question about 'best practices for repository branch management' on one of our whatsapp groups. This is commom query. 'bad branching strategy' or 'no strategy about branching' are very common mistakes in project teams. These mistakes can seriously impact the teams productivity and quality. Unfortunately very few manager/scrum masters or tech leads really understand devastating impact of 'bad version control practices'. In this blog, I am attempting to explain my views and logic behind various practices that I recommend.

Mistake : Too many branches

A developer need to understand the difference between a 'branch' and a 'tag'. Many times teams use 'branch' where tag is sufficient. 'branch' is an 'active line' of development. Common practice is product teams is to support 3 previous versions (i.e major releases) for bug fixes and one new release'. For example your current release is Ver10 and you may supporting major Versions9, 8 and 7. Essentially you have 4 'lines of development'. Then you need 4 branches. Ideally you should checkout 'only' the  branch that you are working on. There is no need to checkout all branches. Since 'branches' represent 'live lines of development', once you stop supporting a particular major release, you should 'delete' the branch for that release. Typically you will have 4 to 6 branches and many/many tags.

Mistake : Creating new branch for every minor release

Assume a major release is 'version 9'. Then 'version 9.1' is developed on 'version 9'  branch ONLY. Remember 'Version 9' is the supported major release and 'live development line'. Version 9.1 is usually a 'NOT live development line'. Any code changes/bug fixes for Version 9.1 should be developed in 'Version 9' branch'

Common complaint : We spend long time in merging.

This is another symptom of bad branching and bad practices followed by team. Consider following branch scenarios.

1. Release branches for past releases
   
   Lets assume that new releases are developed in 'master' and team is supporting 2 previous release 'Version1' and 'version2'. Now team have done a bug fix in 'Version1'. Obviously customers will expect that same bug fix is available on 'patch release on Version2' and also available when new Version3 becomes available. So every day branches must be merged 'upstream'. i.e. merge Version 1 commits to Verson 2. And merge version 2 commits to 'master'. If you get any merge failure fix them. Daily changes are typically small and can be easily merged. This simple practice ensure that time required to do merges are drastically reduced and bug introduced because of merge problems are almost entirely eliminated.
   
   
2. Feature branches
   
   Many teams create 'feature' branches for every new feature or bug fix. However, they don't delete the feature branch one the feature development is over. At end of 'feature' development feature branch must be merged into 'master' and then delete the feature branch. It is best to use 'git flow' plugin/workflow for working on feature branches.
   
   Typical feature branch flow will be 
   • create feature branch from 'master' (so 'parent branch' will be 'master')
   • keep making changes and commiting in feature branch. Its ok to push feature branch.
   • every day merge 'parent branch' to 'feature' branch. This way any changes to 'parent' branch done by other developers are available to you and any conflicting changes are detected early.
   • once the feature is done, merge the 'feature branch' to 'parent branch' (usually 'master'). Since you are regularly merging the 'master' to 'feature', you will not see any conflicts when you merge 'feature' to master. Now delete the feature branch
   
   In both scenarios 'key' is the regular (preferably every day) merge from 'release branch' to master' or 'master to feature' branch.

Remember It is OK to delete a branch

Remember in version control there is nothing like 'permanent delete'. When a branch is deleted, you will not see it 'branches list'. But that does not mean all the history of such branch is also deleted. Recommended practices is to create a 'tag' from branch and then delete the branch. This will keep the history intact. It will also allow to restore a branch from the tag, if you need to do some critical bug fix in an older (now unsupported) release

Bottomline

Remember 'version control' is 'productivity tool' for the development team and NOT just a backup tool. Learn how to take advantage of the version control system and you will see signficant increase in productivity of your team.  Start by defining policy for 'branch creation/branch deletion and daily merge'.

Manual Code Review of every single change is OVERRATED

Many software companies have this policy that every change has to be manually reviewed and approved by some peer (or senior) developer either before it is commited or before it is merged in main development branch. This practice is recommended by many software luminaries. However, when implemented in a project/product, I found many practical issues with 100% manual code reviews and reached a conclusion that "manual code review of every single change is OVERRATED"

Over years, I realized that manual code review of every single change is OVERRATED. It does not appreciably reduce post shipment defects but does introduce many inefficiencies in your development process. Manual Code Review of every single change usually have -ve ROI. I find that nobody writes about bad side effects of forcing developers into 100% manual code reviews. Recently I found one article and that triggered me to write this blog post.

So here is the list of problems that I found in 100% Manual Code Review process

Problems in Manual Code Review of every single change

1.  ROI on Code Review - 
   
   Is reviewer finding kind bugs in code review such that if they remain undetected will take more efforts than the time spent in Code Review ? If yes, then ROI of Code Review is +ve else ROI of Code Review is -ve.  Most of the Code Reviews have -ve ROI.  
   Reviewer may be a good developer but he may not be really good or may not have an 'eye' for defect. Some years back I did an informal study of 'code review' comments reported in my company's code review system. Majority of the code comments were about 'coding style' or 'comments' or 'naming conventions'. Very rarely a serious bug is detected. Effectively Such code reviews have a '-ve ROI'.
2. Reviewers time and attention.
   
   Typically Reviewer is mostly one of the senior developers. He/She also has their own commitments on new feature development. Usually these commitments take priority over code reviews. Hence Code Reviews remain stuck in queue and total feature development time increases unnecessarily (elapsed time from start to feature is delivered in end user's hand).
3. Team's Most productive developers are 'reviewing' rather than 'writing new code'.
   On the other hand, if Senior developers spend majority of their time doing reviews, then 'most productive developers' are effectively not writing any code. Either case results in lower productivity for the entire team.
4. Lower developer productivity while fixing bugs reported during code reviews.
   Code review is helps only if review happens within short time writing the code (preferably within a day). However, in general actual review happens after many days. In this time, developer loses the context of code. When finally the code is reviewed and he/she has to fix something in the code, it takes longer because now developer has to 'get in the context' again. Effectively it lowers the developer's productivity again.

Over year's almost every team that I have worked with has made this mistake and effectively reduced the productivity. How do we fix this ? Whats the alternative ?

How to regain the productivity lost by "manually review every code change policy" ?

1. Institute "Zero Warnings" policy for your code.
   This is easiest and most effective way to eliminate bugs. Every new version of compiler improves in ability to detect potential problems and report them as 'warnings'.  Set your compiler to 'highest warning' level. If you are using Visual Studio, turn on 'report warnings as errors" setting. Fixing warnings is 'practically no-brainer'. Warnings have to fixed immediately. DO NOT wait till end of sprint or end of release to fix warnings.
2. Take advantage of Static Analysis Tools for your programming language.
   Every programming language now has static analysis tools (linters, tools like Klocwork, Coverity etc). This Wikipedia article will give you a list of static analysis tools. Make static analysis part of your 'CI/CD' pipeline. Make sure that static analysis bugs are fixed within day. DO NOT wait till end of sprint or end of release for fixing static analysis errors.
3. Identify your critical files and review only those manually.Stop reviewing very single line of change. Identify your critical files (use complexity analysis, analyze version history to find most frequently changed files etc).  Usually 80-20 rule applies 20% are your critical files. Mark those files in system. Any commits in these files should trigger your manual code review process. Manually review these critical files ONLY after warnings and static analysis bugs are fixed.

Development processes/practices followed in a typically software development team usually have serious inefficiencies. By using 'common sense' (rather than following common practices) it is possible to achieve an 'order of magnitude' (2x to 10x) improvement in the team's productivity and delivery quality. It DOES NOT require a change in methodology (like move to Agile) or any new expensive tools. It requires some disciple and taking advantage of many low hanging fruits. The results are usually visible in about 3 months. 

[Shameless Plug]If you want to know how to improve your team's productivity by 2x to 10x, I am available for 'consulting/coaching'.

References

1. Code Reviews Do Not Find Bugs - How the Current Code Review Best Practice Slows Us Down
2.  

Things you should do after joining your first job

This blog post is for my friends who recently graduated and now joined their first job. 

You have now joined a company and started working. Your responsibilities have now changed. You are now an earning member of your family. The habits that you develop in this first year will determine your future (in your career, in your earnings, etc). So what are the first things you need to do ?? 

Given below is a partial list of things that you need to do immediately or start doing regularly.

1. Buy a medical insurance. 
   You will already be covered in your company's medical insurance or you may be covered in your parent's medical insurance. If you are covered in parents medical insurance, that cover may now be over.  Also it is unlikely that you will stay in the same job. If you change that job, start freelancing, may be between the jobs then you may NOT have medical insurance cover during that period. As you become older, it will be more difficult to get medical insurance. So Buy a Medical Insurance on your own. See if you can get 'family insurance' plan. Add your parents to this insurance.
   
2. Start Investing and building your Financial Portfolio
   Don't spend all your salary on parties and malls. Learn the basics of investing in Mutual Funds, Shares and other financial 'instruments'.  Few years later when you want to buy a house, get married, go to honeymoon, do it with your own money. Don't depend on your parents.
• At bare minimum start creating Fixed or Recurring Deposits in your bank account. 
• All investment companies like ICICI Direct has short courses  that introduce you to basics of investing. Attend those courses.
• Register for SIPs (Systematic Investment Plans) for Mutual Funds/Shares. SIPs will allow you to start investing in small amounts but regularly.
  
3. Start Investing and Building your Knowledge PortfolioBuilding your knowledge portfolio as more important than building your financial portfolio.Sometimes your company will reimburse some of these expenses. Remember The money you spend on books, courses etc are NOT expenses. They are investments. Invest in learning. These investments pay off many times over.
• Buy Books. Don't depend on company or other libraries. You must create your own library of favourite books and books critical for your work. For example, if you are in a programmer you must have your copy of 'Code Complete2'
• Join online courses like Coursera, EdX, Udacity. Pay for those certificates
• Attend conferences. 
• Join Professional Associations like ACM, Computer Society of India, Stepin Forum and meet-ups
  
  
4. Start Investing in your Communication Skills and Business Etiquette
   Good communication skills are critical for your career advancement. One of my mentors gave me a critical advice at the start of my career. He said
   

   "Nitin, what you know is important. But who knows what you know is EQUALLY important"

   "Who knows what you know" gives you opportunities. For that to happen you must be able to clearly articulate your thoughts and ideas.
   
   
   • Practice to write good professional emails and documents. Don't write 'bcos, yo, etc' (i.e.typical sms/whatsapp slang) in your official mails, mails to your boss or colleagues.
   • Practice to speak fluently in your mother tongue and in English. Consciously avoid saying 'You know' or 'ya' in every sentence. 
   • Join organization like Toast Masters where you are practice your presentation skills
     
     
5. Learn to deal with A**holes
   You will find some a**holes in every organization. You have to learn to deal with these on your own. Your parents, brothers/sisters etc are not going to help you now. You will encounter 'passive aggressive bosses', 'vining co-workers', people trying to emotionally blackmail you for various reasons/agendas.
• Read books of Prof. Bob Sutton (No Asshole Rule,  The Asshole Survival Guide: How to Deal with People Who Treat You Like Dirt )
• Learn some meditation. You can do it on your own. You don't have to attend some fancy/expensive class. Checkout Quiet Kit
• Develop your own support system - Your friends, colleagues with whom you can talk and share your problems, who can help you with suggestions and intelligence.
  
6. Find a Mentor
   Your first team/Manager has a HUGE and disproportionate impact on your career. The habits you develop in your first project/team/job, stay with for life long. Make sure you develop 'Good habits'. Make sure to work in a team/manager who will help you learn and develop the good habits.
   
   Check this comment from Prashant Kale. I fully agree with this advice
   
   Do you feel you can reach to the expertise level of your manager/current mentor in 3-4 years? THEN you have 'bad role model'.  Find out someone where you must feel "To reach to level him/her, it will take me 10 years'.  When you find such person, stick with him/her. Stay continuously in touch with him. Meet him/her regularly. Get his/her advice. Discuss your problems/career choices/aspirations openly with them. 
   It is really really difficult to find such Gems. When you find one, make sure you don't ignore or lose them. (NOTE : I was fortunate that I found many such Gems in my initial years in Telco and In Geometric Ltd. It shaped my career. I still keep in touch with my mentors.)
   If you feel your current mentor/team is not adding value to you, change the team (may be even the company). 

If you have any other suggestions to add to this list, please write a comment.

[Update]  I posted this article on LinkedIn. There are many thoughtful comments and advice posted  on this article. Check the replies and suggestions on LinkedIn 

Recruiting programmers through Hackathon/Techathons from Colleges

Last 2 years in Geometric Ltd. we recruited few freshers through Hackathon/Techathon from I2IT college.. And it worked very well. I believe the student we did not select also got benefited tremendously. I am documenting the idea and logistics and various tips/tricks in the hope that it will help other colleges and companies to implement similar programs.

The whole idea of recruitment Hackathon got a push by a chance meeting with Ms. Aruna Katara. Later I met Aruna and her team with few other members from Geometric Ltd. in I2IT campus. We got such a tremendous response from everyone at I2IT college, that within 3 months of initial discussion we had our first hackathon in I2IT.

Problems in typical Campus/Fresher Recruitment process

Typical campus recruitment happens through (a) short listing through General Intelligence test, (b) a technical interview (c) HR interview. Depending on the company there are additional steps as well. If you pass through all these steps, you get offer letter. However, this process has many flaws/problems in practice.

• Someone who performs well in General intelligence test may or may not perform well in actual programming/design tasks
• Technical interviews are many times superficial. Esp. if the student is not from computer science background, then it is difficult to judge his aptitude for programming in interview.
• Also if the person is introvert, is not fluent/comfortable speaking in English, then he/she may have difficulty in cracking interview (technical or HR). So a really good programmer may flunk in interview and may not get selected.
• Many times good programmers are not class toppers. So short listing using some cut off percentage based on college exam marks does not work well.
• It is very difficult to judge if the student will work well in team or not from the interview. Software development is a team activity. Hence it is important to judge student from team work perspective as well. (Group discussions does not really give any idea about how the person will perform in team)

Typical Techathon/Hackthon Recruitment Process that we followed :

• This process is for one college. All the students studying in final year are eligible to participate in Techathon/Hackathon. Typically its 3 to 6 student per team. If number of teams are high (e.g. more than 20 teams), then some short listing happens through review of hackthon project proposals.
• Hackthon winners may or may NOT get job offers. Mentors observe participants and record their observations about initiative, knowledge, programming quality, working in team, etc. Job offers are maded based on these observations. There are NO technical interviews or general intelligence or any other tests. Selected candidates go directly for HR interviews. And if selected from HR interviews, get offer letters.
• Before Hackthon we conduct various sessions for Students so that they can develop their ideas for hackathon. These sessions are conducted by Geometric Ltd. mentors and not outside trainers. For example,
  • Mindmapping - We encouraged students to use mindmap for brainstormng and developing their ideas
  • Basics of User Experience Design
  • Basics of Version Control using Subversion (so that teams can easily coordindate their work)

Logistics of Hackathon :

• Along with College we identify a 'big enough' Hackathon Area in the college campus. On the day of Hackathon, this area is equipped with tables, power outlets, LAN/WiFi connections, some rest/sleeping arangements. College takes care of these items
• Geometric Ltd. took care of (a) food arragements (i.e. lunch, dinner, snacks, 24 hour availability of tea/coffee)  (b) T-Shirts for all participants with Geometric Logo (c) Awards for winners and participation certificate for all participants and other misc items. (d) other branding related activities
• Geometric mentors are present (typically 8 to 10 mentors) through out the event to help participants if they get stuck.
• College Faculty members are present to help students.
• Actual Hackthon is a 24 hours Event. We typically start on Friday 6.00pm and we end the Hackathon with Award ceremony etc on Saturday 7.00pm.
  • On Friday 6.00 pm, Hackathon starts with a very short (Max 30 min) inaguration ceremony.
  • We typically have 3 team status updates during hackathon.  (a) Just before dinner on Friday (b) Saturday morning before breakfast (c) Saturday morning before or after Lunch. Status updates are very brieft. Teams have to give a quick update on where they are , if they need help on anything, if any team needs help then a mentor is assigned to that team.
  • Around 3.30/4.00pm on Saturday judging starts. Judges go to every team and see the demo. Team gets 5 to 7 minutes to demo what they have done and there is a brief Q &A.  Powerpoint presentations are NOT allowed.
  • Teams are judged based on innovativeness of of idea, completeness of demo, quality of demo, etc.
  • Around 6.00pm Saturday, award ceremony starts.

Identifying potential candidates for recruitment

• We create a 'whatsapp' group of Geometric Mentors. During 24 hours Techathon, Mentors continously post their observations about students and teams on this group. Observations are typically related to quality of ideas, team work, programming knowledge ,programming quality and aptitude of specific students etc. 
• At end of Hackathon, We email the archive of this discussion to all mentors and then delete the whatsapp group.
• After Hackathon, we ask college to send us the Photographs of each team with names of Team members clearly marked.
• Using the observations posted on Whatsapp group, we identify pontential candidates. Each mentors shares his opinion,observation and experiences of identified candidates.
• The names of these candidates and team photographs are cross checked to ensure that there is no mistake. 
• A final list is prepared and shared with Recruitment Team. The recruitment team then coordindates with Training and Placement office of College for final HR interview and offer process.

Few unique ideas from Geometric Ltd. recruitment Techathon 

1. Many companies invite 1 or 2 teams from many colleges and then select students from these teams. We decided not to go in that route. Our observation were (a) same 2-3 teams from a college ends up participating in multiple Hackathons.  (b) hence larger student population do not benefit from these events (c) same team participates in multiple hackathons and show the same project in those hackathons, essentially defeating the purpose of hackathon.
2. With our model, different companies can go to different colleges and do the Hackathon as outlined above, many more students will benefit from it.
3. Typically Hackathon happens in July/Aug timeframe. The teams can further develop these hackathon projects as their final year projects.
4. We keep in touch with selected candidates during the next one year. Last 3 years we conduct quarterly Techathons in Geometric Ltd. We invited these selected candidates to participate in our Techathons. Candidates then work with Geometric Teams in our internal Techathon. This one simple idea helped in various ways.
• we kept in touch with college and students.
• it created a bond with those candidates.
• Because Geometric employees closely worked with these candidates in Hackathons, they developed personal connnections with these students.
• When the studentsjoined Geometric after completing their degrees, It was much easier to place these students in various teams compared to other fresh joinees. Mainly because many Geometric project/product teams already knew about them and were ready to welcome them immediately.

Aknowledgement - 

These Hackathons were enormously successful because of support and cooperation from many people. In case I missed anyone, I am sorry. Feel free to remind me and I will add.

• Senior Management of Geometric Ltd.
• Geometric Ltd. Recruitment Team (esp. Sandip Panat, Kamal Dunani) ,
•  HR team (esp. Rakhi Sinha, Anwesa Sen) 
• and Very Enthusiastic Techathon Volunteers (Pratik Jain, Sagar Oak, Rajeshwari Purohit, Bhaskar Sinha, Hemant Shah, Ajit Vaze and Many others. It is really difficult to list everyone name here) 
• I2IT College Faculty and Students (esp. Ms. Aruna Katara, Dr. Vaishali Patil -I2IT Principal, Prof. Ravindra Joshi, Prof. Adesh Patwardhan and his team).

May be Indian Software Developers are just not good in programming

 Today I was reading an article 'Maybe today’s Navy is just not very good at driving ships' about problems by US Navy in light of two recent ship collisions.


What stuck me the how similar the problems are with the problems faced by the Indian Software Industry.

1. Compromising on training of new comers (in the name of saving cost) and assuming that they will learn 'on job'. Typically these guys then screw up 'on the job' which has much higher cost. But this cost is never really visible. It remains hidden behind individual project failures/cost.
2. Project Managers and Team leads afraid to go to seniors/mgmt with anything that might look bad for them. They did everything to protect their own reputation to ensure that they get promotion. 
3. Environment is not about becoming competent software developer/project manager but about looking out for yourself.
4. Decisions made for saving money have now “posed more leadership, logistical and administrative problems,” 
5. (Navy) culture rewards checking the box on qualifications, passing inspections and stacking resumes with career-minded assignments.

For short term company gets 'reduction in cost and hence better profitability'. In Long term company is doomed. (growth stops, good people start leaving, company is sold, etc).

Unfortunately in Indian context this is not just problem of few companies. Its a 'pandemic'.  That is why we (i.e. entire Indian software industry especially small companies) are in BIG trouble.

 

We desparately need lot of Good Passionate Coders. But we also need companies which really really value these passionate programmers.

I cannot do much about companies really giving importance to core coding skills. However, from Sept I will do my bit to develop the next generation of Passionate Programmers. If you want to know how, read about the Concept of CodeGym.

Characteristics of Software Technical Expert - As documented by Hemant Shah

Hemant Shah listed these characteristics of a Software Technical Expert in a mail to participants of Accelerated Technical Expert Program. I think this is a great list and forwarded this mail to various other Teams in Geometric Ltd. I am reproducing the list here as it will be great reference to everyone.

(PS - Hemant has uncanny ability to simplify complex ideas to simple core concepts. If you are in GeometricPLM/HCL Technologies, don't miss his sessions) 

 

While Nitin has been articulating the qualities which he wants to see in Techincal Experts,
Here is a list of things which has been compiled.

I understand that it might sound too much of super-human-like. Also most of the things you would already know.

This is just to document things in a single place.

Note that not all of them are unique or mutually exclusive. Some of them might be repetition of already mentioned points, with a different view point.

Technical Expert

1. A Technical Expert should be able to design a software.
2. A Technical Expert should be able to implement a software.
3. A Technical Expert should have a wide-ranging experience.
4. A Technical Expert should be the go-to person in the team for Technical queries.
5. A Technical Expert should be able to give Technical Presentations.
6.  A Technical Expert should be able to make, review, evaluate a Technical Proposal.
7. A Technical Expert should be able to formulate Technical Guidelines for e.g., Technical Coding Guidelines etc.
8. A Technical Expert should be able to evaluate a new software and give recommendations.
9. A Technical Expert should do Technical Bench-marking.
10. A Technical Expert should be aware of / read technical standards.
11. A Technical Expert should be aware of / read latest things available in his/her field. 
12. A Technical Expert should be member of Technical bodies. 
13. A Technical Expert should write Technical Blogs.
14. A Technical Expert should be able to compare and evaluate two software.
15. A Technical Expert loves challenging problems and attempts at solving them.
16. A Technical Expert should answer queries which are posted on Technical Forums.
17. A Technical Expert should take part in Technical Competitions. 
18. A Technical Expert should be a judge of a Technical Competition. 
19. A Technical Expert should attend Technical Conferences / Events. 
20. A Technical Expert should be a Speaker at Technical Conferences / Events. 
21. A Technical Expert should be able to guide / mentor new comers in the organization and the project team.
22. A Technical Expert should be able to analyse technical reports / findings.
23. A Technical Expert should have some preliminary business sense. 
24. A Technical Expert should be aware of the various tools available in his/her field of expertise, or should be able to find out and figure out.
25. A Technical Expert should take part in Techathons, Hackathons. 
26. A Technical Expert should have in-depth knowledge of a particular topic / subject. He / she should be an authority on that subject. A Technical Expert should have broad knowledge of other areas. 
27. A Technical Expert should have broad knowledge of the various Software Development Processes
28.  A Technical Expert should be part of the Technical Evaluation / Promotion of Individuals. 
29. A Technical Expert should improve the efficiency of the Team on Technical
30. A Technical Expert should share his/her knowledge across multiple domains.
31. A Technical Expert should share technical information with others.
32. A Technical Expert should inspire others also to become a Technical Expert.
33. A Technical Expert should do external Technical Certifications. 
34. A Technical Expert should be an innovator. 
35. A Technical Expert actively contributes on Social Media. 
36. A Technical Expert knows how to build a technical team. 
37. A Technical Expert challenges his / her peers with technical problems.
38.  A Technical Expert comes up with other challenging problems. 
39. A Technical Expert should be a curious person. He / she should be an early adopter of a new technology. 
40. A Technical Expert comes out with challenging test papers / question papers for the next generation to solve.
41. A Technical Expert should be able to talk to, articulate things to non-Technical folks like Human Resources, Business, Finance, Sales, etc.
42. A Technical Expert should be able to simplify complex topics so that other non-technical folks or other technical folks are able to understand and comprehend the complex topics.
43.  A Technical Expert should be able to take Technical Interviews. 
44. A Technical Expert should be able to sustain a dialog with other Technical Experts. 
45. A Technical Expert should be able to teach others about the Technical Skills which he/she has acquired.
46. 48.  A Technical Expert should be sincere, perseverance, able to express, diplomatic, great inter-personal skills, approachable. 
47. A Technical Expert should be an avid reader.
48. A Technical Expert is a Guru.
49. A Technical Expert is a Final Authority on Technical matters. 
50. A Technical Expert is a Role Model for others.

Understanding DevOps Core Concepts - presentation on Slideshare

Few days back I published my understanding of DevOps on slideshare.

DevOps - Basics from Nitin Bhide

DevOps Imperative for Enterprise Apps like PLM – Part 3

In Part 1, I wrote about how implementing shorter deployment cycle is imperative for companies like AutoX (i.e.  companies like Ford, Toyota's and Airbus) and for PLM vendors (i.e. companies like Dassault Systèmes and Siemens PLM).  And implementing DevOps practices is the way to achieve these shorter cycles.

In Part 2, I wrote about how to achieve the seemingly impossible dream of dream of major version upgrade PLM version in a Auto company in one month and minor version upgrades in a week. What features PLM vendors should add to support this kind fast deployment cycles ?

In this part, I plan to write what changes PLM Customers like AutoX (i.e. companies like Ford, Toyota, Airbus, etc) have to do in their way of working to achieve fast PLM updates.

DevOps for PLM is imperative for AutoX to reduce the maintenance, upgrade and enhancement costs of PLM at the same time taking maximum advantage of new PLM features in day-to-day work.

I am assuming you (Reader) are the AutoX company.

Point 1 : Understand that you are a 'software company' now. (whether you like it or not)

 For you it is actually more complex situation than traditional software company because you have to 'integrate' software into your own workflow. So think about how you will manage source code of your software (configuration management), compiled executables/binaries, release cycles, code integration, feature/bug life cycles, version management, deployment management etc.

Even though you are a software company, you are not probably developing your own software product and you are not a company doing projects for others. You are somewhat like a 'systems integrator'. You have your own unique set of challenges. Unfortunately software literature is usually focused on 'products' or 'projects'. There are very few references available.

Point 2 :You will have to customize the PLM and other Enterprise software for your own needs. Out of The Box (OOTB) will not give you competitive advantage that you need.

1. These customization will be done by your own team, PLM vendor, or some third party development company.
2. You have to integrate code from multiple sources. These code-bases may be delivered at different intervals, with different technology stacks.
3. These code bases will have complex dependencies (sometimes circular dependencies).
4. Compiling these code-bases and deploying them in production is a complex task.
5. Tracking the deployment metrics and production performance is required.

'delivering' this code in production is a 'complex pipeline' of activities. Treat this as an 'assembly line' for software. DevOps is at its core about managing this 'assembly line' for software.

It is possible to apply the 'assembly line' concepts from manufacturing application (coming from Kanban, Toyoto Production System, Theory of Constraints etc etc) to this software assembly line and thereby improve the efficiency of this assembly line

1. Think about dependencies. Identify and break circular dependencies.
2. Treat whole program as 'system' and apply 'systems engineer' concepts to streamline workflows
3. Apply concepts like controlling WIP, reducing batch sizes etc. The features not yet delivered to end user is 'inventory'. Features underdevelopment is 'Work In Progress' inventory. Time Boxed Sprints of SCRUM is essentially controlling WIP and reducing batch size.

So where to start ?

1. Define configuration management tools and practices.
1. Which configuration management tool will be used in-house. Which tools will be used by your vendors
2. Add every customization in configuration management. (including build scripts, database schema migration scripts, deployment scripts etc etc)
3. Define how the code-base delivered by vendor, will be merged in your configuration management tool
4. Define configuration management practices in such a way that you can identify what is changed between version easily.
2. Mandate that the vendor has to deliver 'automated test scripts' along with source code (and not just test results).
1. Major bottle neck in DevOps implementations is lack of automated testing scripts.  
2. If you need to test manually all new features/bug fixes, then the deployment cycle (i.e. your batch size of features increase a lot)
3. Overall not having 'automated tests' reduces efficiency of DevOps implementation
3. Define Integration Pipeline
1. How the code will be merged ?
2. How it will be compiled and executable created ?
3. How it will be 'staged' on a test environment ?
4. How automated tests will run ?
5. How automatic deployment will happen ?
6. Every single step in integration pipeline will be 'managed' in your configuration management system.
7. Once code delivered by vendor (or released by your in-house team), entire integration process should take less than 1 week.
4. Define Integration and release cadence.
1. Make sure integration and release cycles are as short as possible.
2. Make sure that 'deployment downtime' should be as less as possible. Use newer cloud deployment tools like creating on demand Virtual machines, using Docker containers etc. 
5. Define a 'sane' agile change management process. 
1. Make sure 'change management' is part of Integration pipeline.
2. When projects/companies move from Water Fall to Agile (especially with code developed by vendor), biggest confusion is about managing 'change requests'.  
6.  Measure everything in production
1. Use tools like 'fluentd', 'TICK stack', ELK stack to collect metrics from production deployments.
2. Create dashboards which show this production metrics to your team.
3. Share the dashboards with your development team. Let them see how the applications they developed are performing in production.
4. To facilitate this data collection in production, define design/coding practices which will push the data to these systems.
7. In case of mixed deployment (part desktop, part server) define and implement how 'automatic' deployment/upgrade of desktop parts will be done along with server parts
1. PLM systems require integration with CAD/CAM/CAE applications and customization of  those applications.
2. DevOps implementation will require pushing changes in production for these applications as well. An automatic update mechanism will be of tremendous help.
3. Building metrics and bug/crash reporting inside these customization will increase the efficiency even more.

This list is just my initial thoughts. I will keep updating it. :-)

Please share your feedback.

Managing all your passwords from one place

In April this year, my friend Parimal Nagarnaik died after 2 year battle with cancer. At that time I realized how many things we do online now a days. All these websites have a username and password. Usually these usernames and passwords are stored in memory or in browser (e.g firefox/chrome) or some word document. It creates a mess for the family.

Last few days I am searching for a way to manage all the passwords at one place from multiple devices. Also a way to share the passwords with family in case any mishaps. I have found following somewhat practical way.

Keepass : Opensource application for securely storing passwords

First download http://keepass.info/download.html . Keepass is an open source application for managing your passwords. All the passwords are stored in keypass database in an encrypted format. Keepass uses AES/Twofish (two well known cryptographic algorithms with 256 bit key). The main database is encrypted with a key derived from a master password. You have to give the master password to decrypt the database of all other passwords.

How to share Keepass database across devices ?

Now enter all the passwords in Keeepass and save the password database in Google Drive. All your windows devices can share same keepass database. Any changes in one device will be propagated to another device by Google Drive.

Now install KeepassDroid  from Android playstore.                        

Install Google drive app on your phone from app store. Make the keypass database 'available offline'. And then open it directly from Google drive. Google drive will ask 'which app' to be used for opening the file. Select "Keepass Droid" app. Now same google drive keepass database is available to you on your android phone. Any changes/edits you do on phone will be synced to your desktop apps as well.                        

How to share the Keepass database with family members in case of mishap?

You can share the keepass file with your family using the google drive 'share' feature. This way family will have access to your passwords if required.

Gmail has 'inactive account manager' feature. "Inactive account manager" sends a message to google email accounts that you specific and give them access to your gmail. You can specify the message to be sent to these account. Include your 'keepass' master password in this message.

Keepass apps are ported to iOS/iPhone as well. Search for MyKeePass or SyncPass on iPhone appstore.                        

Keepass plugins are available for Firefox, Chrome, IE for managing all your internet password/logins directly from browser. You can get the links for various plugins from http://keepass.info/plugins.html

Understanding Requirement Specs - Canteen Chapati Way

Few days back I went to SEZ tower 3 canteen for Lunch. I usually take full lunch. Now the full lunch menu is as specified in attached image (lunch_menu.jpg). (3 chapati, 1 bowl of rice etc). The chapati's I received are in the next image. (The size of chapati is around 3-3.5 inches diameter). The canteen guy explained to me that he has to give only 3 chapati's as per Menu however he is giving me ONE extra chapati. Do you see the problem ?

Its the size of 'chapati'. The chapati is small. The "requirement spec" (Lunch Menu) says 3 chapatis but it does not specify the size of Chapati. So provider can take advantage of it and serve really small chapati's and still fulfill the requirement as 'specified'. One option customer has is to provide the requirement spec is excruciating details (e.g. specify minimum size of chapati, minimum size of bowl, size of spoon for pickle etc etc). Pretty soon it will very painful to specify and it will be an "over constrained" problem. With so many restrictions, the canteen contractor has no leeway to improve or experiment. End result will be that I (i.e. customer) will not be happy with the service I get.

This is a common dilemma of requirement specs. Somewhere you have to trust the "common sense" of the customer and service provider. If the service provide don't have that "common sense" then as customer you will be forced to change the provider.

Remember we (software developers) are the 'service provider' for our customers. And our customers are also going to expect "common sense" from us.

My code review checklist

I am not a fan of checklists (especially for code reviews). Code review checklists start small and then slowly become really large and unwieldy. After sometime checklist becomes a bottleneck and instead of improving effectiveness of your process, these lengthy checklists start reducing the effectiveness. 

However, there are situations where I used checklists and they worked very well. For example, a Customer Release checklist. There are many small small things that you need to do before sending the new release to customer. Its easy to miss few critical steps. A release checklist has always worked very well.

I was not sure why in typical organization sometimes checklists did not work well (for example, in cases like code review) while sometimes it really worked. What exactly is the difference ?

Sometime back I read Atul Gawande's book 'Checklist Manifesto'. It triggered my interest in Checklists again. As first step I extracted a Code Review checklist from my code review training content. I have used this 'mental' checklist for a many-many years. It has worked well for me even with different programming languages (C/C++, Java, Python, C#, Javascript) and technologies. 

Here is my code review checklist.

Code Review Checklist from Nitin Bhide

PS :  Based on my experiences, information from Atul Gawande's book and from information internet, I have now prepared a 4 hour hands-on session on creating and improving the checklists. Contact me if you are interested.

Simple framework to assess potential risks in a Software Project

If you are in a software project, how do you assess the potential risks for a given software project ? So far I have not seen any coherent way of assessing the possible risks. Usually problems are discovered at really late the project life cycle (i.e. just before release dates) and by that time it too late to take any corrective actions. So a common problem is how to detect possible risks as early in project life cycle as possible ?

However, how do you define the 'success' of a project ?

1. Project is delivered to customer. 
2. Your company got the expected profit margin from the project
3. Customer accepted the delivery
4. Customer's end users are happy with delivery.
5. Number of bugs reported are and hence your warranty costs are low.

Ideally a 'successful' project should include all the above. However, many times you achieve few items out of this list. For example, Customer accepted the delivery and end users are happy with features but there are lot bugs reported and rework is high. Customer has request new features and to implement new features require lot of changes in code etc Hence your cost are high/profit margin is now low. How do you assess these kind of risks ?

Last few years, I have been working on various code analysis techniques (Check my open source projects SVNPlot and TCToolkit).  Based on my experience I am convinced that analysis of code, design, version control history etc gives you pretty good idea about the success or failure of a project. 

Recently I have created simple framework to assess the possible risks. 

First we analyze the project in three ways 

• Code Vs Testing quadrant 
• Requirement Vs Testing quadrant 
• Design Vs Codequadrant

Map where your project falls in each case. Based on which quadrants the project is mapped, will tell you possible risks for your project.

I find that based on various project metrics, if I mentally map the project to these quadrants, I get a 'rough judgement' of kind problems project will have in future.

What do you think ? 

Software Performance Optimization - A Different Skill

For almost every project I worked on in last 18 years, required performance optimization. Now I have become somewhat of an expert in Performance Optimization in various domains. I have worked on optimizing performance in CAD/CAM algorithms, database queries, caching. I have considered alternative algorithms, alternative data structure usage, impact of page faults, impact of caching etc etc.

In every domain few things are different but some basics remain constant. First rule of optimization is "Don't depend on your gut feel about the location of the performance bottleneck". 99% of times Your gut feel is wrong. So you need to use tools to locate the performance bottleneck. Essentially the process boils down to 

1. Identify appropriate tool to generate the performance data. Usually this will be a 'profiler'. But sometimes other tools are required (e.g. for analyzing database queries which are taking long time).
2. Generate the performance data using the tool.
3. Interpret the data and locate the performance bottleneck. This requires some practice (and guidance if available)
4. Study the bottleneck code and find out a way to eliminate bottleneck with least amount of code changes. It is important to ensure that code changes are minimum. Large amount of code change can result in new bugs.
5. Make code changes and test.
6. Generate the new performance data and ensure the bottleneck is fixed. If not, revert the changes.
7. If performance is improved keep the changes and commit it.
8. Analyze the performance data again for the next bottleneck.
9. Repeat the steps 3-8.

For most projects 5 to 10 times speed ups are possible. However, usually project teams find it hard to believe. Recently I worked with SigmaTEK Systems India team for improving the performance of their Tube Nesting product. Together we were able improve the performance of  their Tube Nesting product by more than 5 times.

Sushil Deshpande says 

It was a real pleasure to work with Nitin on several projects, especially related to performance development.

Nitin came on board at a typical situation, where the customer was unhappy about the speed of the algorithm, and there was lot of pressure to improve it significantly more than the current speed.

Nitin showed us how to systematically analyze code using simplest tools possible (emphasis was always on understanding, never too much on tools). His inputs and ideas on how to improve the performance, without having to compromise with the quality of the results, very extremely valuable. In addition to just code optimization using performance metrics, Nitin was very keen on evaluating the algorithm techniques as well, and provided us several alternatives right down to the core level, on alternative approaches to evaluate for performance improvement.

This experience has been a real eye opener for us, and although it sounded cliché, when Nitin mentioned the very first time, that he has been involved in several projects with optimization improvements of 5X are more, it was extremely satisfying to see that he guided us using his systematic methods and principles, to performance gains of 5X + in our project as well.

write small functions

In my teams there is always a rule, that maximum function size is 25 lines. Every time when a new team member joined the group, he/she expressed that it is not possible to follow this rule every time and they will have to write longer functions. So I always told them, Ok, but then they have to convince me that there is no way to break this long function in smaller logical chunks. In my 15 years of experience, no one succeeded. I could always show them a way of logically breaking the function in smaller function.

Many team members asked why 25 lines limit and what is the benefit ???. While I explained the reasons verbally to my team members I thought, this time I will document 'why' on the blog.

1. Entire function has to be visible in one page.
   We write code once and edit it few times, but we read it many more times. Hence the code has to be optimized for easy reading, understanding. If I have to scroll or do page up/page down to read a function it breaks the flow. If entire function is visible on one page, then it is easy to ready, understand and hence debug. It is also easy to spot potential problem when whole function is visible.Since typically editor one page is about 25 to 30 lines, hence maximum function size is about 25 lines.
   
2. Reduce the code complexity
   Code with high complexity is difficult to understand and modify.Generally it is recommended to limit the cyclomatic complexity to 15.Once you have a limit on function size, it automatically limits the complexity to manageable proportions. After all, how complex the code can get in 25 lines ??.
   
3. Reduce multiple returns
   Multiple returns from a function (especially more than 2-3 returns) make the code difficult to understand. I have seen functions which are 500-1000 lines and with 25-30 return statements. Usually these functions end up having many bugs.
   Also in C++, you have to manually add any cleanup (e.g. free the memory or close files etc). before every return statements. (Of course you can use techniques like RAII to simplify the clean up).
   Still with small function size, automatically limits number of 'return' from a function
   
4. Easy to spot errors (especially clean up errors)
   Many times in functions you allocate memory, open files, database connections etc. and you have to cleanup/release these resources. If you have large function, it is difficult spot where all memory is allocated, files opened etc and what point it needs to be freed, files closed. With smaller functions is easier to spot these kinds of errors.
   
5. For new code stick to this rule
   For new code stick to this rule. If you are maintaining/enhancing existing code, it is very tempting to jump into large scale refactoring of existing code in one-go. Don't make that mistake.
   If there is a large function but there are no bugs reported or traced to that function, don't refactor it to smaller functions. Leave it as it is.
   However, if you are fixing a bug in a large function refactor the portion where you did the bug fix into a smaller function. Don't try to break 500 line function into 20 functions in one-go. So if you have a 500 line function, after refactoring it may become two functions of 480 lines and 20 lines. If one more bug is reported in the same function do one more small refactoring. Very soon number of large functions will reduce and code will be cleaner and simpler. Check the Refactoring website and follow the guidelines from Martin Fowler's Refactoring Book.

This one thumb rule has worked well for me in practice. What is your experience on writing smaller functions ? Do you have any such rule which worked for you ?

Insights from ‘The Design of Design’ - Part I

I have good fortunate of meeting/interacting with some great software designers while working in Geometric Ltd and during last two years as independent consultant. I am always intrigued by how an expert software designer thinks and how he learns. As Sir Ken Robinson says the key skill in today's world is ‘knowing how to learn new things’. I think of myself as ‘Thinking Craftsman’ (i.e. someone who is thinking about his trade/craft and strives to continuously improve his/her skills). Hence ‘how an expert designer learns and becomes an expert’ is a key question for me in the quest of improving my own skills.

‘The Design of Design’ is a new book from Fred Brooks (Author of Mythical Manmonth). As expected, it has some great/some obvious insights but most importantly it has great explanations of these insights. In this article, I am going to discuss about insights related to how ‘expert designers become experts’.

Insight One: Exemplars in Design
This is what Fred Books says about 'exemplars'

Exemplars provide safe models for new designs, implicit checklists of design tasks, warnings of potential mistakes and launching pads for radical new designs. Hence great designers have invested great efforts in studying their precedents. Bach took a six month unpaid leave to study the work and ideas of Buxtehude. Bach proved to be much greater composer but his surpassing excellence came from comprehending and using the techniques of his predecessors and not ignoring them

I argue that great technical designers need to do likewise but that the hurried pace of modern design has discouraged this practice. ... Technical design disciplines eager to produce great designs need to develop accessible bodies of exemplars and knowledgeable critiques of them (page 154-155)

‘Certainly lazy or slack designer can minimize his work by picking an exemplar and just modifying it to fit. By and large, those who just copy do not draw on ancient or remote exemplars but only on those that are most recent and fashionable’ (page 162).

There are two things that came to my mind after reading this article. First is ‘Design Patterns’. “In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.”.

One purpose of documenting the ‘design patterns in software’ is to 'make experts insights available to a novice’. In this sense, ‘Design patterns’ fit perfectly into what Fred Brooks calls ‘accessible bodies of exemplars’. Personally my thinking about the software design changed after I studied patterns (especially advantages and limitations of each pattern). Even today I read and reread GoF Design pattern book, articles by Robert Martin, articles and books of Martin Fowler, books like Effective C++ and More Effective C++. Every time I gain some small new insights which enrich my own ‘body of knowledge’. Another recent good book of exemplars is ‘Beautiful Code: Leading Programmers Explain How They Think’. There are positive and negative reviews on this book. For me, this book is invaluable for its insights into how various developers think about a problem and how they come up with a solution.

Second thought was ‘about Googling’. Recently (past few years) I see many developers just google about a problem, find something and copy that code. Many times they just pick up some pattern and copy the sample code for that pattern found on the internet. But since they don’t have any real understanding of the pattern, they end with more problems. While conducting programs on ‘design patterns’ I see participants eager to get sample code rather than eager to understand the pattern, participants eager to get the ‘power point slides’ rather than reading the books and articles. So far I have not found any solution to this ‘lazy or slack designer syndrome’. Bigger problem is many of these lazy/slack designers are considered ‘good/great designers’ in their company because they can rattle of latest technology and design buzz words.

For many years I regularly read blogs, various book and studied how other good designers think out of habit.But I could not clearly explain/articulate a new comer why I am doing this. Now I know how this habit has helped me and how it can help a new comer to study his craft.

Persistent Systems and Mr. Anand Deshpande.

I think in last 7-8 years Persistent Systems has grown by leaps and bounds. I always wondered what is the key to Persistent's phenomenal growth. Few months back I met Mr. Anand Deshpande (CEO of Persistent) during a CSI (Computer Society of India) event. Well, I met him for 10 min but I keenly listened when he was talking to others. I also had a chance to have some informal discussion with few other Persistent employees. I am impressed with clear and practical thoughts and ideas of Anand Deshpande. Consider following ideas.

1. Persistent employees are deeply involved in organizations like Computer Society of India (CSI) and Pune Open Coffe club, ACM Pune chapter

Anand Deshpande encouraged Persistent employees to get involved in organization like CSI, Pune Open Coffee Club for long time. Now Persistent employees are key to these organizations. Persistent also allows these organizations to use its infrastructure like conference rooms, training rooms etc. This policy has given some great advantages to Persistent. The developers who get involved in these organizations usually care for 'their craft'. They are passionate about software and about developing their own skills. Now consider a developer who is involved in CSI and is now interested in changing his job. First company he is going to consider is Persistent, because he already knows the people from CSI work. And Persistent is getting some good developers with such personal contacts.

If this is such a good policy, why other companies don't do it ??

Problem is a company will get these benefits only if it consistently does this for 5/6 years at least. So companies who focus visible benefits in short term will never do this. Most of the companies (i.e. their management) don't have this long term vision.

2. College projects
Typically companies who sponsor college projects do it this way.

• Send a mail to all employees asking for ideas for projects.
• Company insists the project has to be in the technology domain that company works in.
• Usually at most 3/4 people reply. Some time nobody replies
• So company has a list of 3 or 4 projects 
• Since companies don't regularly work with colleges or give the list of projects to colleges, this works on personal contacts of students (i.e. students parents).

Obviously there are no great benefits to students or companies.

Usually companies publish 'list of projects'. Persistent publishes a list of 'mentors' and mentor's expertise areas And this is a Key difference. Now students work on their project ideas. And based on technology and problem domain and the quality of project idea Persistent chooses the projects and assigns a mentor. This way mentor's work in areas of their own expertise. As far as I know, there is no restriction that the project has to be the domain that Persistent works in. 

Now this process works great for Students and for Persistent. Students get to work on their own ideas rather than somebody else's idea. Students have to meet their mentors every week. And Persistent gets to know the students and can pick up good ones. Since the project students already know Persistent and its developers they are more likely to join Persistent than other company.

Persistent is the only company I know who have such practical policy on college projects.

3. Courses for college professors.

Last few years Persistent is running one week course for professors of computer science departments in colleges in the month of May. Again there is unique approach. This course is not about some latest buzz word techniques like 'cloud computing, Sliverlight etc'. This course is about some topic that these professors have to teach in next semester in their college (for example, 'algorithms'). So whatever these professor's earn in this course they will use immediately to teach their students in their colleges. 

Again Professors  benefit, Students benefit and Persistent benefits. We crib about quality of students coming out of colleges and quality of professors in such colleges. So Anand Deshpande concentrates on how to improving the skills of professors and indirectly the skills of students coming out these colleges. Now next time Persistent goes to these colleges for campus interviews, it will get to choose from the best. Also it already knows about quality of professors in those colleges. So it can decide which colleges to go for campus interviews. Again a win-win for everyone involved.

Just three policies told me a lot about Why Persistent is so successful. The secret ingredient of Persistent's success in 'vision and ideas of its founder Anand Deshpande'. My admiration for the company and especially it's founder increased many fold based on just one encounter. 

Congratulations Anand Deshpande for mentoring and developing a great organization. 

And Thanks. Just once chance encounter gave me lot of ideas. I hope I will get a chance to work with you.