From: David Masover <ninja@...>
Date: 2010-11-28T03:50:55+09:00
Subject: Re: Ruby 1.8 vs 1.9

On Saturday, November 27, 2010 11:41:59 am Phillip Gawlowski wrote:
> On Sat, Nov 27, 2010 at 9:04 AM, David Masover <ninja@slaphack.com> wrote:
> > On Friday, November 26, 2010 05:51:38 am Phillip Gawlowski wrote:
> >> On Fri, Nov 26, 2010 at 1:42 AM, David Masover <ninja@slaphack.com> 
wrote:
> >> > I'm really curious why anyone would go with an IBM mainframe for a
> >> > greenfield system, let alone pick EBCDIC when ASCII is fully
> >> > supported.
> >> 
> >> Because that's how the other applications written on the mainframe the
> >> company bought 20, 30, 40 years ago expect their data, and the same
> >> code *still runs*.
> > 
> > In other words, not _quite_ greenfield, or at least, a somewhat different
> > sense of greenfield.
> 
> You don't expect anyone to throw their older mainframes away, do you? ;)

I suppose I expected people to be developing modern Linux apps that just 
happen to compile on that hardware.

> > But I guess that explains why you're on a mainframe at all. Someone put
> > their data there 20, 30, 40 years ago, and you need to get at that data,
> > right?
> 
> Oh, don't discard mainframes. For a corporation the size of SAP (or
> needing SAP software), a mainframe is still the ideal hardware to
> manage the enormous databases collected over the years.

Well, now that it's been collected, sure -- migrations are painful.

But then, corporations the size of Google tend to store their information 
distributed on cheap PC hardware.

> And mainframes with vector CPUs are ideal for all sorts of simulations
> engineers have to do (like aerodynamics), or weather research.

When you say "ideal", do you mean they actually beat out the cluster of 
commodity hardware I could buy for the same price?

> >> Legacy systems like that have so much money invested in them, with
> >> code poorly understood (not necessarily because it's *bad* code, but
> >> because the original author has retired 20 years ago),
> > 
> > Which implies bad code, bad documentation, or both. Yes, having the
> > original author available tends to make things easier, but I'm not sure
> > I'd know what to do with the code I wrote 1 year ago, let alone 20,
> > unless I document the hell out of it.
> 
> It gets worse 20 years down the line: The techniques used and state of
> the art then are forgotten now, for example (nobody uses GOTO, or
> should use it, anyway) any more, and error handling is done with
> exceptions these days, instead of error codes, for example. And TDD
> didn't even *exist* as a technique.
> 
> Together with a very, very conservative attitude, changes are
> difficult to deal with, if they can be implemented at all.
> 
> Assuming the source code still exists, anyway.

All three of which suggest to me that in many cases, an actual greenfield 
project would be worth it. IIRC, there was a change to the California minimum 
wage that would take 6 months to implement and 9 months to revert because it 
was written in COBOL -- but could the same team really write a new payroll 
system in 15 months? Maybe, but doubtful.

But it's still absurdly wasteful. A rewrite would pay for itself with only a 
few minor changes that'd be trivial in a sane system, but major year-long 
projects with the legacy system.

So, yeah, job security. I'd just hate my job.