Sundarrajk's Weblog

Structural Code Quality in the Software Industry

Posted on: September 3, 2012

At the end, on the agreed day the project has gone live. The Users have tested the Application and have certified it as sufficiently bug free; there were no Show Stoppers; the Performance Tests showed that the Application is capable of holding up to the expected loads. There has been a huge celebrations and there a flurry of congratulatory notes exchanged between the teams each one patting the other on the back. The management on both sides are happy to have pulled out, what they believe a bloodless coup.

A few weeks later the users come back saying, “Everything is fine, BUT there is one small change that needs to be made to one of the functionality that has been delivered. This is very important as it is effecting all our transactions and needs to be done immediately.”
After this statement here is the set of activities that happen:

  1. The Project liaison from the development team requests the user to raise a Change Request.
  2. Once the Change Request is raised there is a series of exchanges between the development team and the users seeking clarifications and details of the Change Request.
  3. At the end of this exchange the development team goes back to determine the “Change Impact” and estimates the time taken to make the change.
  4. The user team comes back saying that the effort estimates are too high and wish to cut down on the estimates. The reason being quoted to the development team is that this is a very important change which cannot wait till tomorrow, whereas the real reason is they are finding it difficult to justify the cost as it comes immediately after the management has written a huge check for the development team after the release of the application.
  5. The negotiation process begins and the teams go back to the initial requirements document and the user team is trying to find words and sentences to try and prove that this is a bug rather than a Change Request and that the team should fix this at no cost and the development team tries to highlight the vagueness of the words and sentences to try and bolster its request for a Change Request, to justify its timeline and to justify the requested payment.
  6. Soon one can see sweetness of the release changing into bitterness between the two sides.
  7. In the meantime the Project Manager of the development is trying to get things done more quickly so that she can spend minimum resources and charge the maximum amount to get the maximum profit margin to meet her targets.
  8. The development team is grumbling at the prospect of going back to tampering with the code that they thought was finished and done with. Also now when they go back to the code they find that it has not been written well enough for them to fit in the change requested easily. They rue the day they took shortcuts to meet the functionality requested by the client and not spending a little more time in making the code cleaner and more flexibly and easy to understand.
  9. Soon enough bucked by the success of the project and based on the appreciation received from the management and clients, the best in the project start hunting for greener pastures and start moving on to the next employer leaving the maintenance to the new team members and ones that are not bright enough to jump the ship.
  10. As more and more users start using the system and as the load increases and as the regulations change there is more changes required in the code. Soon the code starts resembling a piece of furniture which had just managed to stand up is being held in place by scotch tape over scotch tape.
  11. It reaches a stage where it is just not possible to fix the code anymore and the end users think in terms of rewriting the entire application from scratch.

The end result is every stakeholder is frustrated with the others. All this happened because of one root cause “LACK OF STRUCTURAL QUALITY IN THE CODE”.

Although many in the field of writing software (this is more from a perspective of software industry in India) are from computer science or similar background, none of them are taught the skill of writing quality code. It is not that it takes longer to write good code with a good structure (although it is perceived so due to lack of knowledge and experience), nor is it that the developers are unwilling to do so (if educated they would be more than willing to do so), it is just that they are not taught to write good code.

Our education (in India) is geared towards testing the memory retention and nary a time is spent in developing the creativity or logical reasoning abilities of the students. This leads to graduates who have a good retention power in terms of memory but are completely unskilled when it comes to working in any industry. Even if they have written some thesis and have acquired a Masters or a Doctorate degree they have no practical experience of how to put their knowledge (or rather the contents of their memory) to good use.

If industry, especially the IT or software industry, in India wishes to survive and thrive it is high time they start getting involved in defining the curriculum in the educational institutes. Without doing this they are never going to get employees who will write good understandable, maintainable code. The last couple of generations have managed to survive as the structural code quality was not in focus then. The clients have now started asking for quality in the code and we in this industry are going to suffer as very few in the last generation has learnt to write good code and most have migrated managing teams over a period of time forgetting whatever they learnt during their coding years. Given this there is a dearth of mentors to teach the new entrants in the industry to write good code. To top this there is cut throat competition with everybody vying to offer services at the lowest cost (as that is the only Unique Selling Point of our industries). This means the industry has to  cut down on time spent to build the software and reduce the cost of the associates used to make this software. Reduced cost of associates means not so good developers which further compounds the problems of Code Quality which leads to bad software. This means next time to compete the company needs to quote a still lower price to win the deal and this is a vicious downward spiral in which most IT companies from India find itself.

It will take a real strong company to lead this industry out of this quicksand into which it is sinking.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


%d bloggers like this: