I enjoy visiting customers, and seeing first-hand how they use IssueTrak. This week several of us visited a very large company who happened to be using IssueTrak in a facility here in Virginia. The reason why they were in the market for an incident tracking application is interesting.
They had developed one inihouse. They showed it to us during the visit. It did the job, but after a few years they wanted to improve it. The person who had written the application had been laid off due to the economy. Another fellow in the help desk knew programming, so he decided to look at the code to see if he could make the improvements they needed.
He looked at the code, and discovered that it was written in Korean! They concluded they could not modify the program themselves, so they searched for web-based ticketing systems, and chose IssueTrak.
There are some circumstances where a custom application is exactly what’s needed. But there are risks involved in creating an application from scratch in-house. Very rarely are such projects completed within the estimated time-frame. Custom applications need to be supported once they are deployed. People are transferred, promoted, or leave for greener pastures. These personnel changes are disruptive on two fronts — when the development and support personnel change, problems with the application cannot be handled. Also, when there are personnel changes on the end-user side, this too can be disruptive, and can create significant support calls to the in-house resource who developed the package.
Problems arising with custom programming because it is written in a foreign language doesn’t happen that often. But we encounter situations on a regular basis where a well-intentioned effort to develop something in-house doesn’t work out, and the organization chooses IssueTrak or some other off-the-shelf package to do the job instead.
