MANTECH

About the Company

MANTECH is manly a laboratory equipment manufacturing company which specializes in creating devices used in water, food, and soil testing around the world. The devices are manufactured in a way which allows them to use smaller volumes, which allows the user to use less potentially harmful chemicals. Which is part of their policy to provide more sustainable and green solutions for testing. The company also offers an automation control software called MANTECH Pro, which interfaces with most of the equipment that the company sells and allows for the automation of daily sample. The development of the software is continuously ongoing due to new hardware being integrated, and the addition of new features.

Goals

The main goals I had for my work terms at MANTECH were to gain a better understanding of how C# projects were built, and the compiling process used in the creation of .NET desktop application. As well as to create a continuous integration and development process for the software. Finally, my last goal was to gain more practice in applying concepts from object-oriented programing into real world applications. I mainly improved my ability to program using object-oriented methodologies by incorporating them into new features I was working on, as well as modifying existing code to more closely conform to them. Then for understanding how the program was built and compiled, I gained the most experience by experimenting with the project and when I was refactoring how the wix installer worked. I also partially automated the installer creation process which was the only real chance I got to work on a continuous integration and development proccess due to time restraints, and it being a low priority item. Overall, I mainly developed my general skills at programing and developing product feature, as well as gaining experience in maintaining and managing product releases. In the future this will help me if I get the chance to develop a continuous integration and development system either at MANTECH or another company.

Job Description

The team sizes at MANTECH were very small with the team working on MANTECH pro being only 3-4 people meaning there was a lot more to be done per developer. Due to this I got work on a variety of features for the software and was given a lot of freedom in the design and implementation of the features.

Debugging

One of the tasks I worked on periodically throughout the work terms was fixing existing issues in the software. The main way theses issues were reported was through the Microsoft Azure software, where the QC team, other developers or the CEO could create tasks to either fix a bug or create a new product feature. Generally, these issues would be noticed during the software testing before a release, and the developers had the opportunity to pick and chose their own tasks to work on. If a particular issue was a high priority Item it would be assigned to a developer either at the daily morning stand-up meeting, or at the daily end of day meeting. One of the main bugs I spent my time working on was making it so ISE probe calibration worked properly. This was an issue which popped up many times due to the feature not being fully implemented in the first place and required each component to be fixed as an issue with it was noticed. Giving me a lot of experience in how to ask detailed questions especially if I had no previous knowledge how a process worked, like ISE probe calibration and how it should work. Which will certainly help me in the future, because I am almost certain to not now about every process I will develop.

Feature Development

During my work term I also got to work on new features for the software, three of the main ones I got to develop was a product authentication and registration system, user permission and role management system, and a custom script import/export system. The product registration system was initially based on an existing product key system used in older no longer supported software for a specific hardware device. I mainly migrated and refactored that code for MANTECH pro, then integrated it into the software so it worked properly. For the user permission and role management system I modeled it after how Microsoft handles roles and permissions to different users, with permissions being tied to roles and users tied to roles. I then integrated the system so certain features of the software would be disabled if the user did not have the proper assigned to there user role. Then made it so a local admin user could manage the roles and users assigned to them in one GUI screen. Finally, I was able to use the system to disable certain hardware for customers, which could be only configured by MANTECH. The last major feature I worked on was making an import export system for software’s scripts and other methods like titration and calibration. The first stem was to refactor and replace the old import export system so that it uses the JSON format rather than xml format, and then made the exporter load the relative dependencies for each item properly. The reason why this was needed to be done is because a script could potentially use a script as well as calibration or any other method, so the latest version of that method had to be added to the JSON being created for export. Resolving the main issue that the old import exporter had. The exporter also kept track of all the hardware being used in the scripts and methods. The importer just needed to be refactored to use the JSON format instead of the XML format. Then the last system I needed to create was a hardware item conflict manager, which could detect and allow the user to chose how an hardware item was configured, if the hardware being imported was different that the hardware already existing in the database. These features gave me experience designing and creating systems in a professional manner that furthered my progress in being a professional developer.

Hardware Integration

One of the new experiences I got to experience in these work terms was working with and developing for hardware. The two items I got to work on was the MiniHub interface, and a new conductivity meter. The MiniHub was initially worked on by another developer, but was then assigned to me, with the hardware library for it already completed, my main job was integrating it so could work the same as the older serial interface the project was already using. The main way I accomplished this was refactoring the code so that the new and old hardware interface objects implemented a generic object interface so that they could be used interchangeably in the code, reducing the amount of time I had to spend refactoring and testing the features which used the interface, and allowing for future interface to be implemented more easily. The new conductivity meter I worked on from scratch and had to create the hardware library for. Giving me experience in sending and receiving commands over a serial COM port connection. Then I refactored how the existing conductivity meter worked so it was compatible with the new Interface I created for the conductivity meter. Overall, I gained experience working with interfaces properly so that future hardware items could be implemented more easily in the future. I also gain experience creating a hardware library which I had no previous experience with and will help me if I should work with hardware again in the future.

Product Release

Finally, one the items I worked on was creating a product automatic updating system. In order to implement this feature, I had to learn how the WIX installer worked and gained a lot of experience on how the windows program files work and the structure on how window applications work. I also created and managed the proccess for creating updates for the software, with every 2-3 weeks all finished changes being merged into development, then a patch and installer are created by the automated proccess I made, then uploaded to the server. From there the QC team tests the bug fixes and new features and makes they work properly. Then if any issues occur with the fix or they notice a critical issue they notify the developer responsible, and it is fixed before the patch is released. This occurred multiple time and I was usually responsible in getting the release ready, then finally actually updating the file that caused the release to be pushed to customers. This gave me a lot of experience with a proccess I had now experience with before, and gave me insight on the benefits of some of the release management systems talked about in class and I experienced in my other work terms.

Conclusions

Overall I greatly enjoyed my experience working for MANTECH, due to the freedom the company gave me in the implementation of products and features. I also enjoyed the opportunity of working with hardware for the first time, and gain knowledge about hardware integration from the team. In the end working at MANTECH gave me a lot of experience working as a professional developer, and working on a new project.