On Monday, November 29, 2010 04:53:48 am Brian Candler wrote:
> >> And you'd be surprised
> >> how... stubborn non-techies can be.
> > 
> > Not terribly. I'm more surprised how stubborn techies can be.
> 
> IME the main problems are:
> 
> * Operational. You have a whole workforce trained up to use
> mainframe-based system A; getting them all to change to working with new
> system B can be expensive. This is in addition to their "business as
> usual" work.

This is what I was talking about, mostly. I'm not even talking about stuff 
like switching to Linux or Dvorak, but I'm constantly surprised by techies who 
use IE because it's there and they can't be bothered to change, or C++ because 
it's what they know and they don't want to learn a new language -- yet they're 
perfectly willing to learn a new framework, which is a lot more work.

> * Functional. System A embodies in its code a whole load of knowledge
> about business processes, some of which is probably obsolete, but much
> is still current. It's probably either not documented, or there are
> errors and omissions in the documentation. Re-implementing A as B needs
> to reverse-engineer the behaviour *and* decide which is current and
> which is obsolete, or else re-specify it from scratch.

This is probably the largest legitimate reason not to rewrite. In fact, if 
it's just a bad design on otherwise good technology, an iterative approach is 
slow, torturous, but safe.

> And to be honest, over time new System B is likely to become as
> undocumented and hard to maintain as System A was, unless you have a
> highly skilled and strongly directed development team.

Well, technologies _do_ improve. I'd much rather have an undocumented and hard 
to maintain Ruby script than C program any day, let alone COBOL.