No Need to Change It
thedailywtf.com
thedailywtf.com
That's why your bank still uses a Mainframe (er, that and the huge cost of transition to another platform, which is part and parcel of the same effect).
It's also why Lines of Code is such a terrible metric. 100 lines of code that I just blasted out != 100 lines of code that has been debugged/tested/used/abused. (ok, one of the reasons)
I was not there when these decisions were made, but in this case it does not seem to. As you add in emulators and new compilers you are adding to your code bases in ways that can introduce bugs and unexpected behavior into the system as a whole, just as surely as changes to the application logic itself.
This chance may be small if the code for the emulator and compiler has been debugged/tested/used/abused extensively, but if you are the sole users and it was custom written for you then the chance is nontrivial. It adds to the complexity and problem points of the overall system.
This not to mention the cost of developing those specialized and complicated emulators/compilers. Depending on how complex the algorithms are there is a good chance it would have been cheaper to rewrite it.
One other thing with the banks. You made some good points about why they still use very old software, but the other one is that in addition to being debugged/tested/used/abused their software has passed regulators. I do not know if that is an issue with this car software producing company, but I doubt it, at least I doubt it is to the same degree.
Not necessarily. You need to think outside the cubicle.
Suppose your company has 100 customers. Each of the customers has 10 employees who are trained to use the old system, and 1 tech support guru who knows how to write handy time-saving macros using the old macro language.
If you, the programmer, rewrite the code instead of spending hours painstakingly constructing an emulation environment for it, you might save several years of your time. But your company will save the cost of:
-- Conducting retraining classes for 1000 customer employees, who may not have any interest in learning your new software. (Though you may imagine that the speed and efficiency of your software is the primary concern of your customers, this is not necessarily the case. It's just as likely that they only notice your software when it stops working the way it always did, forcing them to adapt.)
-- Conducting a more extensive set of retraining classes for the 100 tech support gurus who will need to learn an entirely new way of doing their jobs.
-- Staffing a help desk to lead people through the new software.
-- Hiring and training the trainers and the help desk employees.
-- Finding a way to convince your existing customers to pay for all this -- the training time (for which their employees will want to be paid), the temporary loss of efficiency due to the learning curve, and (of course) the fee that you're charging for the upgrade. You may need to beg and plead. You may need bribes and threats. Incidentally, all that begging, bribing, and threatening can't be automated: It needs to be done by your company's sales and support team, one phone call at a time, and those folks have to be paid too.
-- Fending off competition. A discontinuous change in a company's product line is a scary time. Because what you're asking your clients to give up (experience with your old codebase) may be exactly what has been preventing them from fleeing to your competitors. And because the moment of shipping the upgrade is not only the moment when dreams meet reality, but is also the moment when the customer gets to decide whether to spend another N years stuck with your product. An unfortunate coincidence of timing which has often led to disaster.
All of this could easily be more costly than hiring a handful of "computer-science whizzes" for a year or two of emulation-layer development. And it's why, if you are a computer-science whiz, you should raise your consulting rates. ;)
But you are making an assumption that is not necessarily true. You are assuming that the interface, the part the customers see and use, changes so much that they require retraining.
It would be entirely possible to re-implement the entire thing in another language with no discernible changes to the end user. The end user need not necessarily know that anything changed other than it is now moving faster since it does not have to go through an emulation layer and can take full advantage of the speed of modern hardware.
Moreover, institutional knowledge is valuable. It's not just the code, it's the team of people -- both the users and the maintainers -- who have decades of experience with the codebase.
Change the codebase and you throw that all away. Those of us who use thirty-five-year-old text editors to write software for a forty-year-old OS architecture that's running on a thirty-year-old microprocessor family understand this. ;)
In the case of the aforementioned business, the emulator to run their existing code on an x86 was the right move, because it could buy them a ton of time to move things to a newer architecture -- it's not like COBOL doesn't exist on x86, even today (OpenCOBOL).
Moving slowly because you want to reuse a large, existing codebase with many happy customers is smart. Refusing to budge an inch because you're terrified of adapting to new market conditions... isn't.
COBOL is much maligned, but it does what it was designed to do, and does it well. Business rules generally don't need anything fancier, and the data transfer model (IIRC) matches up well with the paper-based systems that it replaced - so it is straightforward to reason about.
Though I think they were lucky to employ whizzes that were actually whizzes. Compiling COBOL to C would be pretty straightforward, but making a debugging for the original language less so. Though, I guess if you just kept a copy of the original source line and line-number, and your execution model was isomorphic to the original, stepping through, and debugging messages could be pretty straightforward, too.
One last point: the article says the resulting code was slow; but Moore's Law will have fixed this, so they didn't have to.
This might not seem too relevant on people working on the startup scene, but for people working in companies (like I used to too) this has a huge impact. If you don't replace your technology stack in 5 years, it will then have 10, 15, 20 years. What do you do now with 20 years * # programmers effort in code which is stuck in a technology 20 years old?
This is actually a hard problem to solve.
The way out of it is via a state machine.
The task of capturing logic in a state machine that is independent of user interface considerations is a very difficult problem.
People will say "Oh use REST" or CORBA or any number of other things, but actually they're all poor, they don't achieve the claimed independence even nearly if the path tree gets complicated.
This is a very important problem to solve for the future of computing. I keep coming back to it - most recently watching Iron Man. I thought "Imagine there was a world where one man could construct so much software" - you'd need some sort of logic state machine like this to do it in.
Hypercard is the closest I've seen to a solution (it's headed in the right direction), but it's tied to user interface. The system needs to allow developers to declare "text box" or "read only text" or "single select" or "multiple select" to allow different interfaces to wrap themselves to it. And the different interfaces could be web, rich, console, unit test, or even a braile system.