3 ms·

This is an extreme example - so it somewhat hides the fact that stable, debugged code is really valuable. That's why your bank still uses a Mainframe (er, that

This is an extreme example - so it somewhat hides the fact that stable, debugged code is really valuable. 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)

timwiseman 17y ago
You have a good point, and in some cases holding onto old code actually makes sense. 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.
- mechanical_fish 17y ago
  it would have been cheaper to rewrite it. 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. ;)
  - timwiseman 17y ago
    Everything you said is true, and you have some good points. 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.
mechanical_fish 17y ago
stable, debugged code is really valuable 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. ;)
- donw 17y ago
  Point, but note that the editor, OS architecture, and processor are under very active development, and have been continuously improved over the past three decades, and are implemented in a language whose compiler has also kept pace with the times. 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.

timwiseman 17y ago

You have a good point, and in some cases holding onto old code actually makes sense. 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.

mechanical_fish 17y ago
it would have been cheaper to rewrite it. 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. ;)
- timwiseman 17y ago
  Everything you said is true, and you have some good points. 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.

mechanical_fish 17y ago

stable, debugged code is really valuable 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. ;)

donw 17y ago
Point, but note that the editor, OS architecture, and processor are under very active development, and have been continuously improved over the past three decades, and are implemented in a language whose compiler has also kept pace with the times. 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.