Sundarrajk's Weblog

Archive for the ‘IT Industry’ Category

I was at the IBM Software world 2012 at the Renaissance, Powai in Mumbai, India yesterday. The guest speaker was Rahul Dravid. Before the session I was skeptical of what a cricketer who has never been in the corporate would be able to speak to a bunch of people who are steeped in the corporate world of the IT industry. But he surprised me with a his talk. He spoke of three points which helped him in his career and I was left wondering how relevant they are to the corporate world and especially in the IT industry which is where I have been running the rat race for the past 21 years.

The three points he mentioned were:
1. Adapt or fail – Change is inevitable
2. Be the best you can be as an individual in a Team
3. Playing with tailenders (read encourage and coach the young and the not so great players)

Adapt of fail – Change is inevitable
He spoke about how he started playing in the tests and when he met with successes in tests the popularity shifted to the One Dayers where he was considered a liability and was dropped. He said that he took it up as a challenge and learnt to adapt to the One Dayers and history tells he turned out to be pretty good at it. And towards the end of the career the One Dayers morphed into 20-20 and it needed further adapting. The fact that he who was trained to hit only along ground and only in the “V” hit three consecutive sixers in a 20-20 match goes to prove that change is inevitable; one needs to adapt to changes; and if one applies one’s mind, one can adapt.
Nothing can be more apt for the IT industry which is in a constant flux. Technology change practically day to day and the only way to survive is to keep abreast of the changes, learn them and adapt to them.

My Journey and Experience
I started off writing assembly programming in 8085, 8086 and 68000 in the college days. When I joined the industry I was trained in COBOL and C and much to my frustration I ended up in a project which was on IBM mainframe but surprisingly used C, as COBOL was the in-thing in those days on the mainframe. I continued on the project for about 2 and half years before moving into another project in another procedural language PL1 and again on a mainframe. The first one was a pure mainframe project and the second was a client server system in which I worked almost exclusively on the server system. This again lasted for a year and half
In the next set of projects I was on web based projects using CGI and C and this lasted for about year and a half.
For the next project we were in a Client Server mode and used Object Oriented Programming in VB. We were fortunate and got the opportunity to use Interface to a large extent and Inheritance to a lesser extent in the project. The usage of interfaces in this project influenced a lot of my design in the latter period of my career. I was slowly moving from the procedural world to the object oriented world.
With a little bit of exposure to the web world and a not so little, but not so great introduction to the object oriented world I started doing projects in Java and started writing full fledged web applications after about 9 years in the industry. From then on I have been on fully object oriented web applications and most of them in Java. I did dabble around a little with .Net and some more client server for a brief period, but it was not significant. I got hands on only a very little in .Net. All this time I continued to be comfortable with C and helped many a teams with their applications written in C although I never go back to writing anything significant in C myself.

About three four years ago I read about the Functional Paradigm through Groovy. Did a lot of reading around Erlang, Haskell, Scala, Groovy, but so far I haven’t had an official opportunity to work on any project using the functional programming paradigm.
Although the heart is all set to learn the functional paradigm the brain seems to have dulled and I am finding it difficult to make inroads into this paradigm. The lack of opportunity to (read as not being thrown into water to learn swimming) is adding to the frustration.

So like Dravid I have made one switch, but am finding to make the next switch now and I am hoping that it will not lead to my being dropped or having to drop out of this industry. 🙂

So change is inevitable and unless one is ready to adapt to changes one will fall by the side and others will trample over you with nary a thought for the ones who have fallen by the sidelines. One needs to keep reinventing oneself with every major change.

Be the best you can as an individual, while playing in a team
What Dravid said was that even though Cricket is a team game and it is important to be a team player it is equally important to strive for the best as an individual. If taken to an extreme it can lead to a big ego and will push the player to become selfish. But if a player is able to balance this with her responsibilities as a team member it will be a win-win situation for both the team and the individual. Dravid spoke about his stint as a wicket keeper which was not his natural skill. But since the team demanded it of him he became one. As much as he admitted that he is probably nowhere near a good keeper, he was never a bad one and he served the purpose.
This is again something which is very relevant in the IT industry. Most projects require a team and unless the team functions as a whole, while the individuals strive to achieve their best it is unlikely that one would end up delivering a good output.

Although I consider myself to be a good team player, unlike Dravid I cannot claim that I have accepted roles with which I am uncomfortable or I feel I am not adept at. I was and am still OK with playing a role in any section of the SDLC. The one part that I am uncomfortable with is the testing and I have stayed away from it. I consider myself fortunate to have been able to retain my role as a technical player in all the projects all these years. The few times I was asked to play a managerial/administrative role I have refused do take up those roles although the team (or rather the management) demanded that of me.

In this respect I cannot consider myself to be as good as Dravid. I can possibly take consolation in the fact that Dravid never bowled, but then he was never expected to bowl at any point in his career and possibly if he had been asked to he might have that too with enough enthusiasm and with the right spirit and it is likely that he would have succeeded as well as he has in the other roles.

Playing with the tailenders – Coaching the greenhorns
Possibly playing with the tailenders while trying to build a score for the team and for yourself or trying to save a match is possibly one of the biggest challenge that a batsman can face. There are few who can claim to have been successful at this. Dravid says he got inspiration from Steve Waugh who has forged many partnerships with the tailenders like Mc Grath. He said that the biggest boost for a tailender is not that the batsman take a single of the last delivery but it is the fact that the batsman feels confident enough to allow him to face a full over. This was the policy that Steve Waugh adopted. He also took Mc Grath under his wings and encouraged him to improve his batting by giving him chance and forcing him to practice at the nets as a batsman. Dravid spoke of Laxman as one such person who did something similar in the Indian team. The name of one Indian that comes to mind who did this extremely well, in my opinion, is S M H Kirmani. It is not the easiest to build a partnership with the likes of B S Chandrashekar, but Kirmani has done it. Although if one were to watch those matches, it was forged by taking singles on the last ball of the overs.

It is almost the same in the IT industry with so many greenhorns coming into the industry everyday it is sometimes not easy to hand over a task to a greenhorn and sit back and expect it to be done. One needs to take the effort to coach the greenhorns so that they do the right things and counsel them so that they take their careers in the the right direction.

My crib about the Indian IT industry
I said the last bit “is almost the same in the IT industry”. While it is relevant up to a point,  I am not sure it applies beyond a point. One should allow individual to pick up what interests them and what they are good at and help them find a path to grow in the industry using their talents. I am not so sure that everybody having to learn all the skills required in an IT project.

Not everybody would be good at documentation, or management or administration or testing. Does that mean that these should be relegated to the lower rungs of the industry and be left there? No I think everybody has a skill and it is the manager’s responsibility to understand this and ensure that the person is put in a position where she can use her skills and add value to the team. There is no point in asking a person who has little or no management skills to learn it and become a Team Lead or a Module Lead and lead a team. If a person is good at coding or designing they should be allowed to advance their careers along those lines.

Unfortunately this has not been happening in the Indian IT industry. Everybody is expected to get into a management role after a few years and is expected to manage a team, take on revenue goals and earn measurable revenue for the company. Only such people are able to grow in the Indian industry. Technical personnel rarely enjoy the status that the sales personnel, administrators and managers enjoy in the corporate. This has led to an unfortunate situation where people who cannot manager are managing, people who cannot sell are selling and people who can design and code are designing and testing. This is one of the biggest reasons why the quality of output in our industry is very very bad.

I am still awaiting the day when this realization dawns and there is a change. Hoping that it will not turn out to be a pipe dream.

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.

Here are a set of things that an aspiring IT engineer should know before graduating. This will help the graduate get into companies more easily and should help them thrive in the IT industry.

  1. Databases
    • Good understanding of Tables, Views, Stored Procedures
    • Good understanding of Primary Keys, Foreign Keys, Unique Keys
    • Understanding of Triggers
    • Good understanding of Joins and role of Cartesian Product in Joins
    • Good understanding of Outer Joins, Inner Joins, Equi Joins
    • Basic SQL
    • Will help if one understands Clustered and Unclustered Indexes
    • Understanding of correlated sub-query will help
    • A very good and clear understanding of what is a Transaction/Unit of Work in a database. What is its significance and consequently how databases help one achieve maintain ACID properties
  2. Algorithms
    • Good understanding of different Sort Algorithms and their performance and where they would be used.
    • Good Understanding of different Search Algorithms and their performance and where they would be used
      • Binary Search
      • Linear Search
  3. Data Structures
  4. Object Oriented Programming Concepts. A good understanding of the OOPS concept helps a lot
    • Good understanding of Encapsulation
    • Good understanding of Polymorphism
    • Good understanding of Inheritance
    • Good understanding of what is public, private, protected, friend
  5. Languages
    • A good understanding of the C Programming Language always helps.
      • A good understanding of Arrays
      • A good understanding of pointers and pointer Algebra
      • A good understanding of file handling
    • A good understanding of the C++
      • A good understanding of Objects
      • A good understanding of virtual functions
      • A good understanding of Operator overloading
    • A good understanding of the Java language
      • A good understanding of Objects and Classes
      • A good understanding of packages
      • A good understanding of classpath and what role it plays in Java
      • A good understanding of JDBC
        • Connection (How to make one)
        • Statement (When to use)
        • Prepared Statement (When to use)
        • Callable Statement (When to use)
      • An understanding of Interfaces and Abstract classes will help.
      • An understanding of J2EE (servlets and JSPs) will help.
      • An understanding of what are EJBs will help.
      • A posting on good set of Java Tutorials for everybody.
    • An understanding of .Net and its principle will help
      • What is CLR?
      • What is an Assembly?
      • What are classes and Name Space?
  6. Operating System
    • A decent understanding of what happens at boot time
    • A decent understanding of environment variables and where they are used. Especially key ones like PATH, LIBPATH etc.
    • What is compilation?
    • What is linking?
    • Understanding make files will help.
    • Understanding of DLL and .so files and how they are used also help.
  7. Systems
    • Understanding of threads and processes
    • Understanding of heap and stack memory
    • Understanding of Big Endian and Little Endian
    • Understanding of ASCII, and different UTF
  8. Protocols
    • Understanding of TCP, UDP and Multicast Protocol
    • Understanding of DNS server
    • Understanding of FTP Protocol
    • Understanding of HTTP Protocol
  9. Scripting: Understanding of Scripting languages
    • Some Understanding of JavaScript
    • Some Understanding of other scripting languages like
      • Ruby
      • PHP
      • Python
      • Perl
  10. Markup Languages
    • Understanding of HTML and HTML tags
    • Understanding of XML
    • Understanding of XHTML
  11. Testing
    • Some testing details like black box testing and white box testing
    • Boundary condition testing
    • Assertions
  12. SDLC
    • Basic Understanding of Software Development Life Cycle
    • Documentation to be created through the Life Cycle of the Software Development
    • Idea of what are ISO and SEI CMM Processes

Categories