Garbage In,Garbage Out

"Garbage In, Garbage Out" or GIGO was one of the first computer acronyms that I learnt, and one that my cousin hammered into me. I should never expect the computer to identify the invalid data that I had entered and still give me a valid result. What this taught me was to check all the steps in my code and to always check for user stupidity as far as input data was concerned. I must admit I have been tempted to be complacent, I have succumbed and even paid the price, but nevertheless I have tried my best to adhere to this as much as I can.

Over the last one year, I have had the chance to work on a project involving a huge amount of coding. The amount of coding that we did is way above the usual coding done by my department. We are more into package tool implementation. So when projects like this come around, maniacs like me are in demand.

I realized during the course of last year that the quality of programmers in my company has fallen. And each time I read a story on the internet saying "if you want to eliminate the need for programmers, then outsource your project" or talking about the lack of quality in the code produced by developers in India/China and other outsourcing hubs, I am pained and the scenes that I see around me don't do anything to reduce the pain.

Garbage In, Garbage Out.

Back in the days when I started to write my first program, I was taught BASIC. C and Pascal were around, but I was taught BASIC so that I could appreciate the basic fact of programming - a set of instructions, nothing more.

When I did move to C and use #include and functions and recursion, I was merely applying structure to the basic set of instructions.Pointers, data structures etc were new and challenging topics and the fact that I crashed my code bu not freeing up memory was a learning step. So today when I write in Java and Python, I still remember how things work under the covers - Java and Python are written in C.

But the guys I work with nowadays are not aware of all this. Most of them were introduced to Java as a course in the semester, with a lab that taught that very basic programming tasks, nothing big or as a 5 day crash course in the company boot-camp. They know things,but never used them in anything big and most of all lack practice. Practice is what makes you good at programming, the more you practice, the more problems you face/analyze/solve the better you will be.

In the hurry to get up to speed on the latest buzz words, we are forgetting our basics. We don't teach the kids the best practices of programming, the way of analyzing a problem effectively and the optimum solution. We tell them the buzz words, a few samples,few lines of code using Eclipse or some such IDE and thats it - certified and project ready. In reality they cannot write 200 lines in one day.

No wonder when you approach a project with such resources, the results take ages to get to the desired quality. They finally get there because people realize things on the job,learn on the job and then deliver.

Is this the best way to go? Can we not improve the situation?