4 ms·
I think the more interesting thing about these ancient programs is the question of why projects to modernise them fail over and over again. Of course we can alr
by zigzigzag 10y ago
I think the more interesting thing about these ancient programs is the question of why projects to modernise them fail over and over again. Of course we can already guess many of the answers without even reading any post-mortems, but obviously these organisations were able to execute complex IT projects once upon a time and over the years lost that ability, leaving them stranded with ancient systems.
In the case of MOCAS I'm going to assume it's all of the standard reasons: weak management, absence of competition, over-reliance on the same small pool of defence contractors that know how to navigate byzantine federal procurement rules, etc.
- coldtea 10y ago>I think the more interesting thing about these ancient programs is the question of why projects to modernise them fail over and over again. A lot of it is because they fail the KISS principle.
- bch 10y agoSpecifically, suffer from second system effect [0]. [0] https://en.m.wikipedia.org/wiki/Second-system_effect https://en.m.wikipedia.org/wiki/Second-system_effect
- coldtea 10y agoYeah. They should just replicate 100% the old system first, and then, only after testing, and 1-2 years on, start adding any new features...
- craigvn 10y agoHow do you justify to the person paying for it that you are are going to spend money to build essentially the same system? Often they don't really care if it is COBOL rather than something newer. The only way to justify is if the maintenance costs are higher than the redevelopment costs.
- mherrmann 10y agoI think you just answered your own question (?) Tell them about the maintenance costs, the difficulty of adding new features or the foreseeable impossibility of finding programmers who know COBOL.
- coldtea 10y ago>How do you justify to the person paying for it that you are are going to spend money to build essentially the same system? Obviously in that: 1) It will completely work with your existing clients etc, because it does exactly what the old one does, with no wild new features and untested stuff. 2) It will bring your old legacy app up to date with a modern language, being able to run in modern hardware, maintained by readily available programmers for hiring, etc. 3) It will allow you to start to add all kinds of features a couple of years down the line, as the remake proves a success, and any minor issues are ironed out. 4) It's much less of a risk of some total rewrite, with a new architecture, ambitious plans, and the idea that you can just migrate the data and switch over, since those "second systems" tend to fail, and over-shoot their costs. >The only way to justify is if the maintenance costs are higher than the redevelopment costs. You forgot the opportunity costs. Enabling them to be more agile, add new features, take advantage of modern pool of programmers, etc., is important, even if they have first to build an identically behaving version of their legacy app.
- tluyben2 10y agoWhile we were building a web frontend on top of an insurance system written in Cobol running on a mainframe, another team was trying to port that Cobol to Java. I often talked to those guys as we were in the same IT basement and indeed, they were to port it and 'and some things'. That project failed while ours is still running on that Cobol system.
- paulddraper 10y agoExactly this. "Do it better" is contagious.
- tluyben2 10y agoCan't edit (yet?) but obvious typo 'and = 'add.
- jmngomes 10y agoBecause that usually involves understanding a complex, mission-critical legacy system with no documentation, no support and implemented using little to no methodology or best practices.