4 ms·
The Cobol code is mostly handling transactions that result in money going from one account to another. The people who own that money tend to scrutinize this ve
by dzdt 5y ago
The Cobol code is mostly handling transactions that result in money going from one account to another. The people who own that money tend to scrutinize this very carefully! So after 40 years, pretty much any bug that occurs in practice has been squashed out of existence.
This doesn't mean that every function in the code works correctly for arbitrary inputs that appear to be allowed by the function interface (formally a bug!) but it does the right thing for the inputs that have historically been provided (in practice very stable and reliable).
That kind of reliability makes it hard to rewrite the code. There are cases for historically unused input combinations where you have no particular reason to believe the old code is bug free. So when your rewrite produces a different result in an obscure case, it is a long and painful business logic task to decide which version is right.
- lmm 5y ago> The Cobol code is mostly handling transactions that result in money going from one account to another. The people who own that money tend to scrutinize this very carefully! In my experience that's only true for a minority of them. The likes of e.g. VAR calculations were often straight-up wrong. And even for monetary transactions, you only have to look at the UK post office lawsuits where the code was simply wrong but rather than checking the code they spent years assuming that any discrepancies were the results of employee theft. > This doesn't mean that every function in the code works correctly for arbitrary inputs that appear to be allowed by the function interface (formally a bug!) but it does the right thing for the inputs that have historically been provided (in practice very stable and reliable). It's stable and reliable as long as nothing changes. But the world is always changing. > That kind of reliability makes it hard to rewrite the code. There are cases for historically unused input combinations where you have no particular reason to believe the old code is bug free. So when your rewrite produces a different result in an obscure case, it is a long and painful business logic task to decide which version is right. Right, but in practice you get an absurd double-standard. The old code is just as likely to be wrong as the new code, but no-one cares about the business logic, they only care about whether the result is the same as the old code.