My first experiences with PeopleSoft began back in 1996. At the time, I felt fairly comfortable with at least the basics of SQL, but PeopleSoft was a mystery to me. Working for what was then Andersen Consulting (now Accenture), my first assignment involved converting thousands of purchase orders into PeopleSoft Financials.
After spending days reading any available technical documentation I could find, it became clear that only through SQL tracing could I learn what I needed. It was only this method that afforded me the opportunity to build information online and then “watch” what PeopleSoft did with it. The only problem I found was the challenge in actually following what was contained in the file — it took me so much time to get through it that I often questioned if I should start over and do it again to make sure I had not missed anything. Considering the high risk in making mistakes doing this type of work, I started trying to automate this process. Using Excel (the best tool ever built for a computer, in my opinion), I was able to simplify my effort by creating macros that could help parse through the file. Although this solution had its merits, in the end it still involved a significant number of manual steps.
Over the next several months, I found my dependence on trace files only growing, as the value contained within them became somewhat of an addiction. I found they were also the shortest avenue to solving problems with broken COBOL batch processes or online pages (then merely panels on a 2-tier platform). In addition, I could quickly learn new online functionality, automate online steps, and many other tasks at work. The consistent barrier was merely the format of this file.
After spending months working on these files each day, I decided to build a tool to solve my problems. I felt it would be a tremendous help to my productivity if I could just see a list of the tables affected and what type of statement (Insert/Update/Select/Delete) was involved. For many applications, the UI design process can be tedious (and I should know, since I worked at Usability Sciences in college); for Pace-Trace, however, I was the customer, and I knew exactly what I wanted. The first version was developed mostly while flying (at the time I was living in Dallas, and working at clients in both Atlanta and Cincinnati each week), and gave me the product I envisioned.
Recommendations for enhancements came after distributing the tool to other PeopleSoft implementers. In addition, I can be a tough customer, and was using it every day for my job, so I had a fair number of change requests as well. The current version reflects enhancements, bug fixes, and updates to support changes in the formatting of the trace file from PeopleSoft. For me, this is one of several must-have tools for any PeopleSoft implementation, and the only one for which I can not find a replacement. Believe me; I built this because I felt I had to, not because I wanted to.
Above all, my intention with this product was to make it easier for people to do their job. A more far-reaching goal was to actually increase the audience of trace file users; just because the file is difficult to read does not mean that only technical people can use it.
Want my full professional life story? If you are not bored enough already, click here to view my resume.