As a student, I couldn’t wait to graduate; I was pursuing a course in engineering and was looking forward to be called an ‘Engineer‘.
By definition, an engineer is:
A professional practitioner of engineering, concerned with applying scientific knowledge, mathematics, and ingenuity to develop solutions for technical problems*.
When I finally received my degree, it gave me a sense of power, that I was now professionally qualified to design and develop ingenious solutions in my field of study.
My destiny landed me a job in this industry. My job at SAP was to give life to a software product; it is still engineering, but I was no longer an engineer here.
I became a “Developer“.
Being in a development organization, SAP provided me a very challenging, yet rich learning experience.
I was a part of an organization which created wonderful applications that would make our customer’s run their businesses better.
The joy of watching your code work magic by translating into purchase and sales orders is a phenomenon that is better experienced than explained.
The success of your efforts is realized when more and more customers buy the software that you developed.
As is true of any commodity in our lives, using a new product is always an exciting experience.
But with the excitement comes the realization that the product does not completely cater to all your business needs.
So the next obvious thing to do would be to turn to the vendor for help.
This is where a maintenance organization would step in.
Being in the company for a good 7 years now, I have witnessed the metamorphosis that the product that I helped develop has gone through.
If I thought that developing the product was a tough task, I have come to realize that maintaining it is tougher.
Maintenance provides one with immense opportunities to learn.
It is quite the common notion that maintenance is not exciting. On the contrary, a fully developed product gives you a lot of insight on how the business was envisioned during the time it was designed and how you can incorporate changes into your product in order to cater to a dynamic business model.
More often, the team that designed and developed the product is no longer available for clarifications.
This leaves you with the task of understanding yourself as to how the product was designed and most importantly why it was designed that way.
Years and years of enhancements on the product leads to redundancy and performance deterioration.
Imagine you bought a spanky new house and kept stuffing it with home decor without clearing out unwanted objects, then you end up with a house that is not inhabitable anymore.
This is better noticed by a person maintaining the code rather than one who wants to enhance it and this is a wonderful opportunity to do your bit to enhance the quality of the product.
My experiences in a part maintenance and part development organization has taught me two important lessons.
1. Learning and expertise is not gained out of software creation alone.
2. Innovation does not end with software development; maitenance opens up vistas for innovation in the area of technology.
*Source: Wikipedia – http://en.wikipedia.org/wiki/Engineer