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

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

Awake Proning

Experience of Contributing to Smart India Hackathon

Talking about my experience of 4 years of Contributing to Smart India Hackathon and trying to summerize it in 4 mins. 

Smart India Hackathon is largest hackathon in the world. In this year's hackathon 60,000+ students participated

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 

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.

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.

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.

Simple Code analysis with TC Tool - Analyzing code duplication

There are many code duplication tools available (opensource and commercial) like CPD - Copy Paste Detector or Simian. However CDD (Code Duplication Detector) in TCToolkit has some unique advantages.In a previous blog post I have explained why I wrote CDD

• It uses excellent Pygments library for parsing the source code. Hence all the languages supported by Pygments are supported by CDD for duplication check.
• It is reasonably Fast.  Last few weeks I spent some time optimizing it for speed.
  For example, on my Dell laptop it detected 164 duplicates in 1445 files of Tomcat source code in 45 seconds.
• It can output duplications in multiple formats. 
• In simple text format.
• In HTML format with 'syntax highlighted' duplicate text fragments
• It can also add Cpp/Java style '// code comments' in the original source code.
• It create a matrix visualization of duplication to identify any duplication patterns. See the example below for Tomcat source (org/apache/coyote/http11) directory.
  
  
  

Here is the command line that I used for tomcat code analysis

cdd.py -l java -o javadups.htm

To see all the options available

cdd.py --help

There are few other simple code visualization tools in TCToolkit like TTC (Token Tag Cloud) or CCOM (Class Concurrence Matrix). I will explain their usage in later posts.

Give it a try and tell me your opinion.

TCToolkit Update (Version 0.6.x)

When I consulted to companies on improving their source code (for refactoring it, improving the performance, detecting the design bottlenecks, detecting problematic files etc), I needed a way to quickly analyze a code base. However, there were not many tools available which gave me a quick insight on code. Commercial tools like Coverity, KlocWorks, Lattix etc are expensive. Because i could use it, I had to convince my client to 'license' it and that was difficult. Hence about 2 years back I wrote few python scripts to quickly help me analyze a codebase. Later I open sourced these python scripts a 'TCToolkit'.  

Recently I have done significant refactoring and updates to these scripts and also added some new scripts. Also I have moved the TCToolkit code to Bitbucket. (https://bitbucket.org/nitinbhide/tctoolkit ). 

Important updates are listed below

1. Improved the performance of CDD (Code Duplication Detector). On my Dell laptop, subversion C code base (around 450 files) can now be analyzed for duplication in about 90 seconds.
2. Now I use d3js library for generating the visualizations. Token tag cloud (TCC) now uses d3js for generating the tag cloud. CDD uses d3js for displaying the 'duplication matrix'.
3. A new script 'CCOM' (Class Co-occurrence matrix) is added. This script analyzes the code base and finds out which classes are used together. It displays this information in matrix form.
   
   For example, class A has class B as member variable, or member function of class A uses class B as parameter then class A and B are treated as occuring. If a function takes two parameters objects class B and class C, then class B and C are treated as 'co-occurring'. If classes are co-occurring, then chances are there is some dependency between their functionality and hence changes in one MAY impact other.
4. smjstreemap.py : This script generates a treemap visualization from the excellent freeware code metrics tool SourceMonitor. It also uses d3js for displaying the treemap.

 Give it a try on on your code base and see what kind of insights you get about your project.

CSS and Icon sprites - tips and tricks

[NOTE : This post was originally published on  BootStrapToday blog as "CSS and Icon sprites – tips and tricks"]

We used image sprites for icons on bootstraptoday.com for version 2.0 and also in the latest version that we are working on (version 3). Quickly I realized that making sure that the icons looks same on major browsers is a task in itself.  For example, when you have an empty 'span' element which is supposed to display the icons, different browser will treat it slightly differently. Some browsers will give it a height/width of 1 character, some browsers height same as line height but width will be 0. If your icons are not arranged properly then putting those icons on buttons with consistent look & feel is a nightmare.  So here are few tips to define the icon image sprites and to use them effectively.

1. First and most important tip is to have single sized icons in one sprite and arrange them in a grid. So if you have two icon sizes (e.g. 16px and 24px), make two sprites. One for 16px icons arranged on 16px X 16px grid. Another for 24px icons arranged on 24px X 24px grid.  Check the twitter-bootstrap icons.


2. Use LessCSS or (some other equivalent) to define the icons css.


3. Use span as 'display:inline-block'.  Typically span elements are inline elements. And you cannot define width/height of an inline element. Since we need to place the icons inline but need the flexibility of defining width/height, use 'display:inline-block'.


4. Usually set the 'vertical-align:text-top'. This will align the icons to text.


5. Use content:"". It will satisfy browsers which need to see text inside the span.

Here is a sample .less css fragment to be used with an icon sprite and

@icon-sprite-path:url(../images/icongrid.png);     /* url of the image path */
@icon-grid-size:16px;

.icongrid {

background-image:@icon-sprite-path:
background-repeat:no-repeat;

/* the element should be placed as 'inline' but we need flexibility to define width/height, padding etc*/
display:inline-block;

/* to ensure that each span is 'icon-grid-size' by 'icon-grid-size' square */
padding:@icon-grid-size/2;

/* to satisfy browsers which don't like empty elements */
content:"";

/* align the icons with text */
vertical-align:text-top;

}

/* define individual icon positions in sprite */
.testicon { background-position:0 -16px; }

Now you can use the icons with spans. For example to append the 'test icon' to some text, use

<div> ... your text here
<span class='icongrid testicon"></span>
</div>

Acknowledgement : I picked up some of these ideas by going over the twitter-bootstrap css and icon sprites.