“First, solve the problem. Then, write the code.”
In a terse email which landed in my inbox from one of the senior most executives of the company complaining that the report he has been using is so untrustworthy & for a good measure used the oft repeated lingo ‘for the nth time’ to drive home his frustration. It was my early days at this new client place and as a functional consultant my task was to ensure that the system is configured to business needs and wondered why I am bearing the brunt. But this email got me thinking, I began to dwell and soon realized that I had a myopic view of the larger picture. It then dawned on me that the person on the other side is looking towards me for solving his genuine problem and not to receive an email saying ‘Hey am a functional person, its not in my court to fix issues in custom reports’.
Armed with this enlightenment, with all the gung ho which comes in the initial days to make a good impression, promised so much, that even the most glossiest of marketing materials would be put to a shame. I guess it is in moments like this which makes one realize that innocence is bliss but it is something which invariably leaves you in abyss. I wrote a long and detailed specification document of what the report is supposed to do from a business perspective and my half cooked knowledge of programming made me even to suggest the lines of code which had to change to the development team who were in Europe. A couple of weeks went by with no response, while I had to bear a few more unpleasant emails from the senior executive.
An intervention by the IT manager ensured that a meeting was set up with the developer and to my horror realized that he spoke very little english if any. It was my naive thoughts which led me from one pit to another before long realizing that my highly verbose emails to the developer who wasn’t fluent in english wasn’t getting me anywhere. I finally stuck to drawing a few boxes and graphically representing the changes which I was requesting which struck a chord and got the work done. With a huge sigh of relief in having got what the executive requested for, made a presentation to him on how the report is now reliable and trustworthy. In one sweeping statement the executive pulled the ground under me. He said he was expecting the report to be in a specific way both in structure and content which was totally different from what it was.
The very thought that I had to go through the entire cycle again with developer whose language I was unable to speak, made me get jitters. I then realized the value of the statement of John Johnson, as instead of spending time in understanding the real issue and fixing that I ventured down the path of coding. I pondered long and hard on whether I should learn the language which the developer was fluent. In a eureka moment I felt let me learn ABAP using which I can communicate with developers from different countries. I was confident that as a drawing communicates a design engineers views, ABAP would help me communicate with the technical person better be it in writing a more understable pseudo code or the ABAP code itself (At this point I pause and say it is not necessary that all Functional personnel must venture down this path. It was just my choice).
My initiation into the world of programming was with ‘C’ and much earlier with ‘FoxPro’ (don’t know if anyone remembers it anymore) and as with most people my early programming days got me into the procedural mould. It was a fantastic way of writing the program in neatly segregated sub-sections where the flow of the program was largely based on input section a middle processing block culminating in the output blocks. It was with this background I dived into the world of ABAP, where I initially dabbled with creating simple infoset queries with little or no coding within it and slowly progressed to develop a complete report.
The progress achieved was personally pleasing given the fact that my learning was entirely based on reading material available online coupled with trial and error till it succeeds. However I realized that to transform myself from merely thinking in terms of lines of code I needed to bring in some class, in this case quite literally. I had heard the terms and concepts used in Object Oriented Programming (OOP) but had yet to inherit the understanding from the masters in the field and encapsulate it in my mind. In all earnest I began taking baby steps into this wonderful world of abstraction and soon realised that the few programs which I had developed were a total nightmare not just in terms of maintenance or re-usability but even in its fundamental design.
I finally decided to take a proverbial “leap of faith” but with a safety net i.e. by combining OOP with the procedural method in which I was relatively comfortable. I know at this point the OOP community might call it a sacrilege of OOP. I went about building this report by splitting into what I call business function blocks, where-in each block would provide the main program with a specific business feature. From the conception stage itself I was clear that if anything I needed to make the presentation visually appealing for the person using it while providing accurate data with fast execution time. I decided to use the GUI Splitter Controls, Chart engine etc. to provide in a single screen the ability to view the information both in digits and in charts.
As I went about building the code, I realized just how steep a learning curve it was & at times made me to give up. I must admit if it was not for the umpteen technical blogs / wikis etc. which I read many times over written by some good hearted souls my adventure with OOP would surely have been a OOPS!. After much trial and error I finally got the program to deliver the functionality and for a good measure I was able to use classes to do my code testing, which was a personally enriching experience. After the typical code review and inspection the report was made available to the requestor. It was quite a success and at that moment I felt the effort was worth every bit of it.
My journey towards using OOP concepts was not to become a developer, but to ingrain the intricacies of the wonderful world of Object Orientation. This entire experience has now armed with better insights, enabling me to seamlessly harmonize my business process know-how with the technical world to deliver solutions to real world problems. I write this blog as a tribute to all those “gurus” of mine from whom I have learnt & who in choosing to share their knowledge have lit up a little candle of knowledge within me. My journey has just begun and hope it will be a high CLASS experience.