Lesson learned while on a mission critical conversion project
Here’s a project I worked on where I learned an important lesson.
The client was a global consumer products company, and the project was to convert an Access 2.0 application to Access 95, which was a conversion from a 16-bit environment to a 32-bit environment. I’m not even going to claim that I understand what all that means, except to say that there were a lot of procedure calls to the Windows Application Programming Interface (API) that needed to be changed over. This application was used to facilitate preparing the company’s profit/loss and balance sheets for all of their business units around the world. Hereafter, I’ll call it the “financial reporting application”.
Where I went wrong was that I didn’t test portions of the program as I converted the code. It demonstrated a skill in programming that I needed to learn, and I learned that lesson the hard way because, once the program was “converted”, i.e., all the code compiled correctly with no errors, there were other application errors that began popping up all over.
I created a tool to help me keep track of all the errors and the steps taken to resolve them and provided the client with daily progress reports.
As I think back on it, I would have done much better if I had taken more time to understand how the program worked in its prior environment and tested the program incrementally as I revised the code.
If you liked this post, click here to share it with your network!
Want to read more like this from Daniel Johnson, Jr.? If you do, subscribe right now!
Get via Email 
Add to Google 
Subscribe to the Feed
Tags: Access 2, Access 95, Conversions, financial reporting application, global consumer products company, Lessons Learned, programming
