Is it surprising that this has happened? No, not at all. Corruption, cooking up figures, cooking up documentation, having special coaching and preparation purely from perspective of clearing an examination are all some form of corrupt practices that are prevalent in India.

A similar situation exists in the software industry in India. What we produce is Working Software, not Quality Software. Most software projects that we execute go through a crisis phase when some hero has to come and rescue the project. This happens after the client escalates the matter to the higher management in the organization and the higher management leashes out its whips and then the right people start coming in and fixing the problem.

The reason for this problem plaguing the software industry is manifold. It starts with the Response to the Request For Proposal (RFP) from the client. Typically the RFP is a very high level requirement from the client. In addition to the few lines of requirements the client also typically mentions the timeline by which they wish to have the project ready for deployment. In the eagerness to win the project the software contractors squeeze as much as possible, make all impossible assumptions, assumptions of both requirements and the ability of the team to develop and deliver the project.

Finally it comes down to price negotiation. The client presses the already squeezed out contractor of further juice. The sales person from the contractor in front of the client agrees to the cuts, possibly in the cost of the project and the to the timelines within which it has to be delivery while at the same time they agree to increased requirements. The sales person does this as she has to meet her sales target and then she is absolved of all other responsibilities.

Once the project comes to the delivery team whose target is to deliver the project in the minimum time with the maximum profit, this team starts cutting down on costs by getting the cheapest resource available. These are capable resource with no experience. This teams starts possibly gathering requirements during which time the actual enormity of the task strikes them and they try to negotiate to bring down the scope. In most cases it is a worthless exercise. At the end of the exercise the requirements are still unclear and many loose ends are left dangling as the team that would have gathered the requirement would have been a novice one and the team that would have specified the requirements would not have know what details need to be specified for this team to design and develop the system.

Now when the design and coding starts in earnest, two problems begin to show; first there would be very few team members who will be really capable of putting together a good design; the second problem will be that there will be even more few team members who are capable of writing good code. Added to this mixture the fact that the requirements were not clear means that the this team starts making more assumptions. The tendency to go back to the client to get clarifications is rare under these circumstances as the leader would say “If you go to them you will get more requirements, so assume and proceed so that we deliver on time”.

Soon the time for delivery will pass and the client will start raising heckles on why the project is getting delayed. One would go through a series of negotiations on how the requirements were unclear and how the client team did not support the development etc and the client would keep telling how incompetent the team developing is. It many cases it will go to the higher management which will send in a Process Team to assess the processes being followed by the team. In most cases it will turn out that the documentation is not in place or is not complete and the process team will now point to this gap as the reason for the delay and now the project team will need to fill in the gaps by creating these documents delaying the project further. The next attempt will be get more people into the project to try and “speed up” the delivery. Soon without many noticing the profit that were planned would have started eroding.

Finally at some point in the development cycle, when the pressure mounts beyond tolerance, the develop team will dump a whole lot of code at the Quality Assurance (QA) team. This team would be equally at loss about the functionality and will go about testing a the application and raise some errors like font is mismatched or message is grammatically incorrect and few such trivial errors. Some of these would be fixed and some would be rejected by the team explaining that it is a feature.

Once it goes past the QA team the application would be delivered to the client for User Acceptance Testing. This team would typically be expected to carry out this exercise in addition to carrying on their routing job. As a result this testing would be given a step motherly treatment and after reporting a few errors this team will go back to doing their routine jobs. They would most likely raise one or two “errors” which would be disputed as “change requests” by the contractor and negotiations would be on to come to a compromise.

The development team will try and fix these problems and make another release going through the same cycle of testing by QA. QA team will typically test the application only for the errors that were raised at UAT and as a result when it goes to the user group for the next round of UAT there would be other errors which would have crept into the system due to these bug fixes and some of these would typically show up in the UAT.

This cycle will repeat a few times before the management gets a tired of the process and charges of incompetency will be traded between the contractor and the client, with the client being more accusatory than the contractor due to the nature of the relationship between them.

Now the management from the contractor will try and send in more senior designers and developers who will come a work “miracles” and get the system functioning much better. This would still not fix all the problems and issues but in all likelihood the project will end up being deployed in production.

Within a few days of it in production one will start seeing functional issues, performance issues, and availability issues with the system. The development team, ill equipped and over burdened will try and resolve the issues and will end up resolving some and bringing in more issues in the process.

This cycle will continue for a few iterations before the client reaches her wits end and escalates the matter to the senior management. Now another set of senior designers and architect will come in and start looking into the system. This team will in all likelihood have a supercilious attitude towards the developer community and will go about berating the entire development team. They will try and fix up a few things and get things working. After a few iterations the system will be functional. It will still not be efficient or error free or perform as good as it could have performed.

If one analyzes the above situation and the situation at Ranbaxy or any other incidents such as constructions breaking down because of bad construction or poor material being used, or cases like the “housing loan schemes” which led to a global meltdown of economy the one conclusion that can be drawn without much hesitation is that these happens due to greed for money. It is not that many of these people do not have money, it is just that one can NEVER HAVE ENOUGH OF MONEY.