Most companies in India are more into production support and maintenance Lot of projects are imported into India for Production support, I happen be successfully completing my 3rd year in production support supporting two major projects. In two major companies.
I was working in a small company during the dot.com days where many companies were working on B2C, B2B products, hopeful of selling them.
During the gold-rush days, I was told that working in Java/J2EE meant that you no longer need to do the same chorus that are being done in Mainframe technologies, As rather than supporting these systems once it will be easier to develop new software than maintaining them just the way we remove components from a PC and replace them with newer components
That prophecy happens to be false, more and more java projects are moving into support mode.
I have become more of an expert in reading code than writing code, most support projects have no documentation and one has to understand the flow and functionality by reading the code and log files.
I happen to see many projects where Support is taken in India without any KT (Knowledge transfer), as the resource managing the project would have left in a hurry.
It would be tough life in support for the initial 6 months (utmost depending upon the complexity of the project). Then life becomes smooth and one knows where one needs to fiddle in case of a bug or Change request, other wise life is routine like cleaning up log files re-starting server ect.
And further more I happen to support projects written in 1999 or 2000 where vector and enumeration are used in abundance and the java version is 1.2
My question is; are we wasting our youthful productive days by working on support projects; if so what is the way out.
What is remedy to keep your coding skill from getting rusty?
You could always refactor code to make it perform better. Working in support does not mean your skills will become rusty. I work in development as well as support and so far things are pretty neat. If you are reading code 80% of the time just so you can change one line, that could suck. However if the tickets raised by your users involve solving hard problems, code changes, etc etc you could learn a lot. I guess it depends on what project you are working on.
It all depends on where you work and how well or poorly your system was built.
If it's a robust system that's been used for the last 10 years, your probably aren't going to get that many requests to fix things. especially if you work for a company that believes in "if it's not broken, don't fix it."
On the other hand if the system keeps crashing and there are tons of bugs, you might get tons of work to improve it, but again it all depends on who you work for. Some companies have software that barely runs, but they don't want to spend money to update the software. So what you have is a bunch of patches, fixes, and nothing more.
Maybe you work for a company that likes new technology and you get a chance to add new features and so on.
Regardless you'll get a chance to improve your skills and reengineering an existing system and fixing one can always lead to great knowledge on how to do or not do something.
One thing that has been constant throughout my career was that the "new technology" was going to make everything fast, cheap, and reliable.
Another thing that has been constant throughout my career was that each new technology failed to magically do so. Whether it was Chief Programmer Teams, Structured Programming, Object-Oriented Programming, Perma-Temping, or Offshoring, each new approach brought benefits, but none of them ever provided the Ultimate Solution.
Software remains a construct part-art, part-science and in some ways, almost organic. You design and build apps using technology that's usually out of date even as you write it, and which will surely be out of date within 12 months. You'll generally have to take shortcuts and apply hacks and kludges to get the thing to work acceptably within the budget and timeframe limitations. And in the process, either it will die and be discarded before it ever goes into production, or it will outlive you, getting more patched-up each year as user needs change.
And, of course, if software ever did get itself to the point where it was self-authoring, we'd all be looking for jobs in another industry.
However, if you feel that you're going to miss out on all the fun, have you considered the possibility of going into business for yourself? Set up a computer at home, find an area that needs good software and develop for it. It's a big challenge, but you may find that it suits you. And, of course, you can pick whatever technology you want to use - at least if you base it on open-source platforms.
Customer surveys are for companies who didn't pay proper attention to begin with.