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).