I work as a rental agent / manager for a car rental company that is running on a rental system that was written in 1972. I decided that maybe it was time for an update. For a bit of background, here is a short example of the madness that we have to deal with from this program daily:
A rental agent must remember that printing on one screen uses "MXC" in the ACT field (everything is based on short codes), which perplexingly stands for "MaXimum display on a Contract", while on another it requires PR (for PRint) in the ACTION field, but several screens use a Y in the PT (for PrinT) field, yet another screen uses Y in the PRT (for PRinT) field, yet another screen requires the user to hit enter (but not the enter next to the letters, as that's a new line character, it must be the enter on the number pad) and then F8, a different but related screen requires simply F8, some screens have a field labeled PRT, which should be for PRinT, but the field actually does nothing and printing is done automatically after going through several prompts, and still more screens have a field labeled PRINT Y/N, which insanely defaults to Y for operations in which another location is already delivering paperwork, and to N for operations in which another dealer will need paperwork.
I decided that I could do a better job than this, so I set out to contact the person in the company that would make the decision to update this. I eventually get through to the VP of IT, who is in charge of this program. I get a bit of information out of him, and learn that my car rental company has its rental program written in IBM mainframe assembler with a little bit of COBOL mixed in. He says that there are no positions open right now, but that I should e-mail him my resume anyway (in case something opens up).
This leads me to my questions.
The first is technical. With the idea of improving maintainability in the future, my thought is to re-write it in a higher-level language than assembly language. My area of experience is in C++, so that is the obvious choice for me. The company is in dire need of an easier way to update the program, as I recently read an article where the man I spoke with is quoted as saying the team worked hard, and they are proud to announce that the program now has support for 5-digit location codes (instead of 4) and 8 digit car numbers (instead of 7). My philosophy on updates, even in situations this dire, is in line with Joel's: http://www.joelonsoftware.com/articles/fog0000000069.html in short, re-writes should be incremental, rather than throwing out everything there was before and starting fresh.
Is there an easy way to integrate IBM assembly with C++, and if so, how should I do it? I am vaguely aware of the asm keyword, but I don't know if it's best to use that or do something else. Is such a plan ill-advised? I do most of my work on Linux using g++ and GNU make, so answers specific to that are welcomed, but definitely not required (since I have no idea what sort of build system they have no, but I suspect almost none).
The second question is more political. How should I go about persuading this company that they need to make the switch? The theoretical cost savings are huge (based on my estimates, the company is wasting an extra million or so dollars per year, just on increased training costs to learn how to interact with the program), but my proposed changes would probably put all of the current programmers out of work, should they be enacted, so there is great structural resistance to change.
edit: I should explain why me modifying what the company already has seems like the best solution to me. I am still open to other suggestions, because this is a monster of a program, however. I've never had a programming job before, so please correct me on any incorrect analysis I might give.
First off, there is the off-the-shelf solution.
From my talks with a few mid-level managers about this sort of thing, one of the main concerns with switching to a new system is the large number of loyal employees who have been with the company for decades and are comfortable with the system by now. If I have the ability to modify what we have, I could maintain the current interface in a sort of 'compatibility mode'. Users already have to log in to use the current system, so I could add the ability to activate a setting when users log in for the 'first' time (after I make this change), where they are given the option to use either the 'classic' interface or the 'new' interface. There is no way I'll find an off-the-shelf solution that allows that, and I think that fears of senior employees getting confused by changing technology would be a major reason for upper management to say no.
My company also owns the software we use; we do not license it. This means that the management I am currently talking to are the same people who could actually authorize me to make a change. With a third-party solution, I would have to get approval from my company in addition to securing whatever rights would be necessary from the company that developed the product we use, which adds an additional hurdle. This would also require convincing the company to give up on "their" product and take some other product, which seems like a greater hurdle than attempting to update what we have, but I could very well be wrong on this issue.
Finally, looking into the future, I don't just want to improve the user interface and fix a few bugs. After I update those 'urgent' issues, I was hoping to update fundamental way the company runs as related to technology. After spending 1-2 years on these sorts of issues, my plan was to go back to management and propose more dramatic changes. There are many ways the company runs that could be fundamentally improved by technology that they simply are not using right now. For instance, each region pretty much operates the same way. The local major airport is the central hub to distribute cars. They are primarily sent on an as-needed basis. However, the airport is used as the home base for all operations. They'll send two people in one car to my location to pick up one car from us that we don't need, then return to the airport with the car they came in, plus what they are taking back (we are 32 miles from the airport). Then they will come to the location 5 miles away from us in two cars to drop one of them off, then return in their other car to the airport. They do this even if the car we sent back is the same kind of car they need near us. I've been with the company for about two years now, and I've only seem them deviate from this in the most extreme emergencies of car shortages (so about three times ever). I would replace the 4 people working in every region with an automated scheduling system that determines what cars go where and try and find the path that requires the least amount of time + miles + drivers to deliver all cars where they need to be, as an example of the higher level fixes I hope to some day add.
However, before I would feel comfortable proposing all of this, I feel it would be helpful to get a toehold in the company and the code base by doing the smaller tasks, like updating the interface. Solutions like outsourcing or otherwise would remove this possibility.
if (m_newInterface)
spaghetti code started to appear all over the code base. Decoupling and refactoring took long enough that, when it was done, most of the users have already migrated to the new interface (think multiple years).