Porting code : Does it help?

You work in a project that manages (create, enhance and maintain) a large software product. Your manager comes to you and ask you to add a new software feature for this product. He has given you complete freedom in deciding on how to proceed. You know that the same software feature is already available in another OS as open source with favourable licensing or from a company as closed source. You can port it instead of implementing it yourself. So the critical question here is should you go ahead and port the code or implement this yourself?

In last few years, I have ported couple of large features while reviewed few large features that were ported by others. There were few very specific reasons why we decided to port a specific feature (I think most of you who decides to port a particular code will be having something similar):

1. Porting the feature will save ample amount of time and in turn money.
2. We will get a well tested code and we will be bringing in less number of bugs into our code base (which we know is a better code).
3. Community (or the company if you have bought the code base) will provide bug fixes and enhancements which can be ported easily so we as such do not need to worry about them.

Now when I look back at some of these ported features, I feel that it would have been better to implement them ourselves instead of porting them. Here are the reasons:

1. In at least one of the cases, the code we ported was not modular enough and did not gel well with our code base. We end up spending lots of time in creating or extending existing APIs in the ported code.
2. In at least one of the cases, we needed to port only one part of the feature but we had to port the whole code and later we realized that there is no way to just compile that part of the feature. It took us lots of time to finally get what we wanted.
3. One of the feature had interaction with operating system and management systems like CLI. These interactions have been standardize in our product. It took us some efforts to make ported code use these standardized interfaces instead of what it was using before.
4. In couple of cases, we decided to own the code after porting as we had made changes so we could not rely solely on bug fixes from the actual source.
5. As the code was not writing internally, none of us knew the whole code which brought in unknown to our code base. If any bug is seen, there was always a doubt that it is coming from the ported code. In any case, everybody thinks that whatever they have written is almost a bug-free code.

Please note that I am not saying porting is bad. What I am trying to suggest is that do not decide to port just because the code is available. Look at the following things before you make a decision:

1. Is the code modular and structured enough that you can integrate it with your software without creating too many new interfaces?
2. Are you looking to port only part of the code? Is this part big enough to justify porting?
3. Is it possible to port the code without making too many changes in the code? This means if you are making too many changes then you may not be able to take bug fixes and enhancements just like a patch. Also in such a case, you must look at the whole code and after porting, you have a similar confidence as if you have written it yourself.
4. Can your management system support be added in the ported code easily?
5. Is the code you are porting is readable and maintainable? Can your team be able to maintain this without the outside help?

I am sure a lot of you would have done this in the past and will do it in future as everybody today talks about re-usability. But my suggestion is that before you actually take the plunge, do ask yourself, will this porting really help?

Also some of you would have done some porting in your software engineer life so far, please do share your experience, views and opinions on this.

Why IP Multicast - My take

When I started my career, I did an initiative on IP multicast and since then I have been working on this technology. There are various articles and blogs in the net that defines IP multicast. I decided to attempt to provide simple explanation. I hope you will let me know if I have succeeded or not. So here we go.

When a PC wants to communicate with a specific PC, it uses Unicast. This is similar to you writing a letter and posting it to your father.

When a PC wants to communicate with all the PCs in a network, it uses Broadcast. This is similar to you writing a letter and a copy is sent to all the people.

Multicast is somewhat in the middle. When a PC wants to communicate with a specific set of PCs in a network, it uses Multicast. This set may contain all the PCs in the network.This is similar to you writing a letter and a copy is sent to only sepecific set of people who want to receive your letter.

I am sure after reading this, the next question is why do we need Multicast? Why not use Broadcast itself? I completely agree. We can use Broadcast instead of Multicast. But is not there a catch? Yes, there surely is. Otherwise people would not have spent time, energy and lots of Rupees in creating Multicast. Here are the two which I could think of:

1. To receive Multicast traffic, a receiver specifically indicates that it wants to receive the traffic. So CPU of a receiver will not see the Multicast traffic if it has not wished to receive it. While in case of Broadcast traffic, receivers of all CPU
2. There are only two broadcast addresses and only one can be routed. While there are 2^28 or 268,435,456 Multicast addresses to choose from and except 255 ( 224.0.0.0 to 224.0.0.255) multicast addresses, all others can be routed. So applications can choose from a wider range of addresses in case of Multicast.

Now we know Broadcast cannot be used and we need something special like Multicast. To start with, Multicast was designed to help in one-to-many communication. Later it was extended to support many-to-many communication. In multicast, sender sends out one single packet and routers forward them towards the receiver. A router replicates a packet if it has receiver on multiple interfaces and send one packet towards each receiver. I will talk about Protocols used in IP multicast in future posts.

So how actually Multicast helps in a network? Here are the most visible aspects:

1. A server needs to send out only one copy of the packet if Multicast is used. If unicast would have been used instead, server would have to send out as many copies as the number of receiver. Right.
2. Network bandwidth is saved. Because server sends only one copy out instead of as many as the number of receiver.
3. As the overall number of packets in the network is reduced, it also helps in avoiding network congestion.

I did not use any network topology to put across my points. It could be a problem but I feel that it will be more satisfactory if you can visualize the whole thing with your strong visualizing capabilities.

I shall be talking more about IP multicast in upcoming posts so stay tuned.

India in IETF

How has India faired in IETF (Internet Engineering Task Force)?

Some people may not be aware of what IETF is?

IETF is a standard body whose goal is to make the Internet work better. 

I have been participating in IETF on and off for couple of years. I was interested in finding out contribution trends in IETF. It was more to find out which company and which country is contributing to IETF. As part of this, I looked at India's contribution to IETF. When I say India's contribution, I am refering to contribution from people working in India.

In last couple of years, while I have seen an exponential increase in the contribution from India, I think it is still far from 'our best effort'. Let me share some statistics to prove my point:

1. Out of around 60 countries who has contributed in IETF, India's contribution keep us at 13th place.
2. Out of around 53 countries currently active in IETF, India comes at 9th place.
3. Out of around 9000 documents in IETF, only 180 documents (around 1.95%) has come from India.
4. Out of around 6700 RFCs created till now, only 72 RFCs (around 1.07%) has come from India.
5. Out of around 15700 authors in IETF, only 67 authors has come from India.
6. Out of around 100 working groups in IETF, authors from India are active only in 29 working groups.
7. As far as I know, till now, there has never been anybody from India who has been a working group chair or Area Director in IETF. 
8. India has never hosted an IETF meeting.

I agree that these statisitcs do not paint a rosy picture. To bring out the relative performance of India, I decided to see this data against some other country and choose China. I choose China for a very specific reason as China and India, both started contributing in IETF around the same time. Let us look at similar numbers for China:

1. Out of around 60 countries, China is at 4th place.
2. Out of around 53 countries currently active in IETF, China is at 2nd place.
3. Out of around 9000 documents in IETF, 583 documents (6.30%) has come from China.
4. Out of around 6700 RFCs created till now, 127 RFCs (1.88%) has come from China.
5. Out of around 15700 authors in IETF, only 337 authors has come from China.
6. Out of around 100 working groups in IETF, authors from China are active in more than 50 working groups.
7. China has hosted an IETF meeting. 

So based on the numbers, its clear that China's contribution in IETF is growing with far better rate than ours.

I just wanted to point out our (India) dismal standalone as well as relative performance in one of the leading standardize body (IETF).

In some future post, I will discuss what we, as individuals, as companies and as a country, should do to improve the quality and quantity of this participation. I would request people to think and post their suggestions on the same.

Credit:
All the IETF data mentioned in this post has been fetched from IETF statistics web page..

Code review : A necessary evil

Do we really need code review? Ideally speaking, we don't. But idealism is seldom practical. If people write their code properly without any bugs, there is no need for code review. But is this humanly possible? Naah!

I have talked to my friends who are working with different OEM companies about code review in their projects. Most of the responses fall under three categories:

1. There is no code review as everybody is pretty good with the code. Also, a lot of regression testing takes care of the bugs.
2. There is code review but not many people takes it seriously.
3. There is code review and everybody takes it very seriously. For bigger code changes, multiple reviewers review the code.

I have been part of multiple projects where we maintained larges software for various clients and we have always been in the third category. So I think I am not qualified to outline the advantages of no code review but let us look at what does a strict code review brings to the table:

1. A reviewer is a different person. He thinks about code differently. So he brings in a different perspective when looking at someone else's code. He can look at the modularity, scalability and maintainability of the code as a neutral person. Believe me this has really helped me (and our projects) a lot.
2. Developers are usually in hurry. They need to finish the current task at hand and move to the next task. A code review helps in establishing that a feature has been implemented as stated in the requirements.
3. Developers are usually bad unit tester. During unit testing, they tend to miss the negative test cases or specific scenario test cases. A reviewer during the code review can identify some of these negative and specific scenarios for the developer to test. This increase the overall reliability of the feature.
4. If you identify the code reviewer smartly, you can use this exercise to train new people in code as well as code review.

All these reasoning looks pretty good but are there any side-effects? Yes, there are.

1. I have witnessed first hand that a some review comments late in the review cycle can create havoc. Developer tries to carry out the change fast as he needs to commit his code and usually forget to handle some special cases which he had taken care in the first phase.
2. A similar situation comes when code review process gets delayed for some reasons. In couple of weeks, developer may not remember why a code is written the way it is written. So when a comment is given in that part of the code, developer is not sure what to do and might end up breaking his own code/logic which was most probably correct.
3. A developer will have to allocate 20% of total development time for review.

There seems to be both pros and cons of doing code review. So what is my take?

I think I will go with the title, 'Code Review is a necessary evil'.

To learn something more on this topic, I would request people who have followed 'No code review' policy to please mention the advantages and disadvantages they see with 'No code review' policy. May be then, we can debate on what makes more sense.

Reasons to start this blog

I am not sure what to write in the first blog entry when you start a blog. You see, I am doing this for the first time. If I ever create another blog, may be, I will have the required experience to write something different.

I had been thinking to start writing a technical blog on Data Communication domain focusing on IP routing and switching, IP Multicast and what it takes to develop routers/switches. This has been in my mind for quiet some time now (around couple of years to give you some clue :( ). I hope I am not too late.

During a discussion last week, one of my colleague mentioned that people who take actions only succeeds. So here I am. Writing first entry for my blog.

I was thinking about the reasons why I would like to start a blog when some similar blogs are already there. So here are the list of reasons:

1. Its being written by me. So anyway there is a difference.
2. I think that using this blog, I can help myself and others who are trying to figure out things in Data Communication domain. I will come back and check on this in a year time.
3. While I can get opinion from some people on some topics but I thought a blog may be the best way to put my views about various technology topics. I think this medium will also help me find are others who have some say on the same.
4. I think I can use this to connect-in people with similar background, experience.
5. Last but not the least, it will help in improving my english writing capabilities and presentation skills as well.

I am sure I will figure out whether I am able to achieve what I set out to in couple of months time. Till then, please help me by commenting, sharing and criticizing my posts as much as you can.

Please say 'Best of luck Bharat'.