Sure, but still there are often ways to deal with this situation on the database level without rewriting the code, by, for example, adding triggers that reformat database fields in different ways for different applications and subsystems. A subsystem would still be writing 2-digit year into the database and the trigger will intervene, convert and store the 4-digit value. And when you read it, it will, again, present it to different clients in different formats. It’s not always possible, of course, but often it is. It’s much cheaper than re-writing everything.

Cranky

Just to clarify what “old code” means in this context: one entity I worked with had a business-critical application with an estimated 7 millions lines of code. The core modules of that application dated from 1954. Yes, that is “54” not “64”. There really wasn’t a full set of source code available anymore (heck, Microsoft claims it no longer has the source code for Windows 95a), but the languages that could be identified included:

• IBM 1401 machine language
• IBM 1401 Autocoder (assembly language)
• COBOL
• FORTRAN
• PL/I
• and the odd bit of Ada™ that crept in somewhere

Now that’s something that’s really easy to test and fix!

Cranky

But. There was a real issue affecting legacy systems. Nobody needed to commission studies to prove this, because any half educated COBOL monkey could understand the point without much prompting. Commissioning studies would really have cost money. Nobody lost their heads, except the victims of the hype merchants. The director of my principal client division at the time read our risk assessment and remarked, “Nobody’s going to die, then.”

But he authorised the work, because he wanted people to get paid, he wanted his staff to be able to do their jobs, and he wanted to deliver a quality service. So we did the work, and fucking dull it was too. But we did it right, because we identified about 250 instances of the date issue in two major systems and corrected them all. Don’t clap, just appreciate that this doesn’t make a good story in the Daily Mail.

And as to the various CTOs like Dave Heasman’s who seized the opportunity to replace other systems which were becoming unsafe, them you may applaud. Good managers all.

1) How many companies would be willing to allow academics access to their codebase (answer: very few, if any). If you’re not inspecting the codebase, then you’re guessing.

2) How many academics would be able to analyse such a codebase, such as to give a sufficiently accurate answer (skills required would include actual experience of reading code and maintaining old code, which isn’t one you acquire in academia – together with knowledge of many computer languages and environments). This would require a huge investment of time and energy, btw, as you’d have to fully understand how the code worked (and it is unlikely to be adequately documented). You can’t just glance through it looking for “date”. Even then, you might not catch all the problems.

3) Predicting how all the systems would interact in a company with complex computer systems (which would include financial institutions, large retail institutions, shipping companies, companies who run significant infrastructure) – would be impossible. We simply don’t have the tools to do this.

4) Even if the above could be managed, the investment of time and resources to do this would be very large indeed. Doing it for multiple companies would be even more difficult.

5) How generalisable would such information be, given the very different computer systems, dependencies, history, business models and culture of each and every company (I’m guessing not very). You also have to take into account that companies also rely (without realising it) on the computer systems of suppliers and vendors.

So in short, such a study would be a huge and expensive undertaking which would rely upon skills that are rare, and cooperation with companies that is rarely forthcoming. At the end of this study you’d have information that would not be particularly reliable, or generalisable.

Not really, and I’m not convinced that you really know what you mean. If you’re arguing that code is modular and exists in black boxes (which can be easily modified), then no, as anybody who has ever had the misfortune to work on old/complex systems can testify.

To give an example. In the case of a database, you might not know what all the systems which access/rely upon that piece of data are. Or how they rely upon it. They might use it for radically different things, or in ways that you wouldn’t expect.

One thing people I knew never asked, and looked at me bugeyed when I asked them in turn, was WHY people would all go bonkers and turn into CHUDs or Mad Max if the power went out and computers stopped working. Partly this is because I live in a region where bad ice storms have been known to knock out massive amounts of systems for days on end, and guess what, we jury-rigged things and helped each other out and very few people died – why should it be any different? And nobody could answer why nobody would think of, and be able to, go in and manually override and get the lights back on and start traffic moving and just keep records on paper, the way we did when the power was out in some towns for a whole week.
—Too much bad television, I say.

We do. We just don’t bother to (or simply can’t afford it, in a lot of cases) put the money and effort into the necessary monitoring and repair of them. (Or in worst-case scenarios, into building them properly the first time, just like the scuzzy contractors who used sea-salt building cement high-rises – it wasn’t that “we don’t understand” how cement works, they just didn’t care since they weren’t planning on living in them.) That’s one reason why we’re slowly dismantling a lot of dams in my state, because they’re not used for anything practical any more, it costs too much to fix them, and they cause problems for the fish stocks. Unfortunately, taking down a dam safely also costs money, which we don’t have, either. Catch 22. So when we have heavy rains and flooding like we recently did, we try to monitor the ones known to be in most danger round the clock and patch them up. Fortunately these are mostly dams that were built well – that is to say, nobody cheated or skimped on supplies or proper engineering and surveying beforehand – it’s just that they’re in some cases over a hundred years old and haven’t been kept up because, again, lack of money.

But looking back on it, particularly considering the discussion in this thread, I have to wonder: without the scaremongers and consultants, would the actual work needed have ever gotten done? Perhaps humans just can’t take on a serious long-term problems unless they are convinced it is a Death Dealing Flaming Asteriod which will cause Doom In 90 Days!!

This is something to consider in relation to the global warming debate I think.

Cranky

Cranky

I think you exaggerate quite a bit here. Computer systems and subsystems in most cases communicate by exchanging files and accessing databases, thus you don’t necessarily have to investigate and modify each piece involved; often you can manage by simply adding intermediate steps to modify input or output files and database fields. If you know what I mean.

The problem with theoretical analysis here is that in most cases it’s impossible to predict whether you’ll have to rewrite a million lines of code or write a 100-line program to reformat the output file. So, as with everything else – you hope for the best and plan (and budget) for the worst…