Summer 2015
Trans Plus is a software company specializing in Windows-based transportation software that was founded in Guelph. They have a flagship program called ‘Fleet Manager’ that is used by trucking companies to manage the logistics of their truck fleets. As a development company, they utilize the scrum methodology to push out new features in a timely manner.
My role changed in my second semester at Trans Plus to be the defect fixer, the branch manager for source control branches as well as the liaison for the development department to the product services department. It was my job to fix all defects that were reported as well as help product services whenever they needed a developer’s insight in diagnosing a bug/troubleshooting an issue.
The role of defect fixer was mostly unchanged from the previous semester except for the fact that the volume of defects coming in every day had increased 10 fold. The increased volume lead to a week of the entire department being dedicated to fixing defects, and it was my job to assign defects to developers in such a way that the priority defects were fixed first.
As the branch manager for source control branches, it was my job to ensure branches were merged to the main branch on time and properly, as well as create and delete branches when needed. There was a daily merge for all defects fixed in the last 24 hours that I was in charge of doing as well.
My last role as liaison for the development department to the product services department was to ensure that all development related questions were answered by me so that other developers were able to focus on their stories. This meant that I had to answer questions regarding recently released bug fixes and features, if the automatic updates were down and give estimates on when certain defects were to be fixed.
I loved my Co-op job at Trans Plus for my second term. Each day posed a new challenge with all the different defects I had to diagnose and then fix without introducing more defects into the system. I looked at each one like a unique puzzle that needed to be solved. This was the interesting part of my job. The mundane part was the daily merge that I needed to complete before lunch in order to push through the bug fixes of the last 24 hours to live production. It was a simple process that was the same just about every time and didn’t require much thought, so I decided to automate it to make my work easier. I saw it as a good opportunity to try to build something from start to finish in C#, as opposed to just adding and fixing features in an already released product.
To start, the process for merging was this:
- Merge the development branch to the production branch, resolving any conflicts that might come up.
- Build the project using the “Release” parameters.
- Run all unit tests. If any fail, fix in the development branch and then restart the process from step 1.
- Check-in the changes to the production branch.
- Run the nightly-build script.
- Smoke test the build on a test computer after updating the Fleet Manager client through automatic updates.
- Smoke test the build on a test computer from a fresh install of Fleet Manager.
- Update the database versions xml file on the live server to reflect the new database and software versions of Fleet Manager.
- Move the current backup to the old backup folder and copy the current build DLL files to the current backup folder.
- Push the automatic updates live by removing the “Offline” flag for the automatic updates service.
I tackled this problem in an iterative manner, building the small and easy features first, and then would move onto the more difficult ones. For me, this was building answers to steps 10, 9 and 8 in that order. For 10 and 9, it was simply learning how to manipulate files and figure out how to give a program the same permissions as the executing user so that when a development team member executed the program, it had access to the restricted servers on our network.
Step 8 consisted of learning how to use the different classes in the System.Xml namespace to read the Xml file and add a new set of nodes to it while following the existing schema. It is a large library and so the sheer volume I had to go through was daunting.
Once steps 10, 9 and 8 were complete, it removed much of the human error from the merge process. I moved onto steps 2 and 3 as they took up the most idle time besides the nightly build in the entire process. They both involved utilizing the vast Visual Studio API in order to do that tasks that were normally executed by hand. Again, the biggest challenge here was figuring out what the best classes/methods were to use from the API. It was also quite difficult to figure out if the build completed without errors from the return objects I received back when doing step 2.
Unfortunately, I ran out of time to complete the rest of the features as my term had completed, however the utility program still removed many of the mundane operations of the daily merge.
During my first week of this term, the company had upgraded one of their biggest clients from the old VB6 version to their new VB.NET and C# version, Fleet Manager 3.0. While Fleet Manager 3.0 had already been released for a year at this point, none of the upgraded clients used the program as extensively as this new client. This meant that a lot of previously untouched modules of the software were now being used thoroughly, which caused the rate that we were getting defects submitted to us to increase by roughly 10 fold.
I had originally set this goal as an ambitious task, confident in my ability to fix the defects fast enough that I’d be able to keep up and eventually be able to call the product “Stable”. I underestimated the difficulty in fixing some of the defects though. Many had increasingly cryptic messages, the worst probably being “The operation completed successfully”, followed by a stack trace usually leading to the initialization of a form. These were rarely reproducible.
While I was able to fix many defects of varying difficulties and slowed the number we were getting every day from 50+ to less than 5, I was ultimately unable to reach my goal as the remaining defects were all either too difficult to track down or deemed too time consuming to fix.
On the first Thursday of every month, the development department would allow any developer to take the day off from working on the core application in order to develop a program that would be deemed as useful to the trucking industry or Trans Plus. The catch being you had to start from scratch and had until 9:00 AM the next day to show what you made. I mainly used these days to experiment with technologies that I had little to no experience with. This meant that actually producing something useful was very challenging.
My first attempt was the Merge Utility program listed in an above learning goal. Features were later completed to make the job of the co-op student less mundane.
My second attempt was to finish a module on a program I had been working for a course in school that I decided to continue on my own time. The program was a “battle simulator” for the online multiplayer game “League of Legends”. It utilized the Riot API to gather data about the game that would allow a user to simulate fights between different champions in the game. There are many different effects that champion’s attacks can have on one another, and the API does a very bad job of sending those effects to an application; through descriptive text. In order to complete this module, I had to build a text parser that would be able to read a champion’s attack description and churn out some sort of data class that would have the different effects that the attack had.
The game itself has many different types of effects, so this ultimately failed as a 24 hour application production.
My third attempt at a hack day was to take the “battle simulator” program I had described earlier and make it look presentable. The application was built using HTML5 and javascript with the Angular 1.X framework, so my first choice was to use barebones CSS3, something I had never done before. It was very frustrating throughout the entire 24 hours and it gave me a new found appreciation for front-end web developers and designers. I was able to make something presentable, and it laid the ground work for my future use of CSS3 in web development.