

No Need to Change It - edw519
http://thedailywtf.com/Articles/No_Need_to_Change_It!_.aspx

======
jwilliams
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
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
_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
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.

------
warwick
I'm not sure why there are scare quotes around the "compiler" in this. A high-
level to high-level compiler is still a compiler.

------
projectileboy
We laugh, but if the company is profitable, well... That's higher praise than
one could give most software projects.

------
andreyf
Heh, cute example, but even being a technologist, I see the business reasoning
here. If the logic of a program was described once, why does it need to be re-
done when the next fancy language comes out? Why can't all languages/systems
be backwards compatible?

------
danbmil99
I posit that they made the right business decision. At any one of the points
where they could have embraced new technology, they were at high risk of
getting into a no-win dev cycle and destroying their business.

------
10ren
I love these guys.

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.

------
mtoledo
The truth on the software industry is: 1) Nobody makes software with a plan on
when to replace it. They just assume the time will come and they'll know in
the future. 2) Rewriting software is _usually_ a bad idea, although there are
some success cases of rewritten software.

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.

------
andreyf
Heh, cute example, but even being a technologist, I see the business reasoning
here. If the logic of a program was described once, why does it need to be re-
done when the next fancy language comes out? Why can't all languages/systems
be backwards compatible?

~~~
cturner
"If the logic of a program was described once, why does it need to be re-done
when the next fancy language comes out? Why can't all languages/systems be
backwards compatible?"

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.

------
terpua
I refuse to re-code my python program in objective-c. Thank you pyobjc...I
didn't need to change it.

