I would add that "the job has failed". The next consultant who modifies the code is destined to break it (resulting in more work required of said constractor, s

I would add that "the job has failed". The next consultant who modifies the code is destined to break it (resulting in more work required of said constractor, so we have a dangerous incentive here). Cobol isn't really the problem here. Its more a problem of the system as a whole disagragating the data manipulation into different parts of the application, different batch jobs, whatever. OOP was intended to solve this problem (at least in a single application) by restricting the mutation and access of the data to a single class. Given a monolithic server model it worked. It is something that many of the modern programming languages completely fail at. Particularly the async oriented ones where its frequently possible to attach routines which mutate the state of an object from pretty much any point in the codebase. Combined with shared database access models/microservices/etc and systems get complex to the point where it takes real effort to logically map out all the individual parts which can read and modify a piece of data. So in a way the current model is very similar to the mainframe batch processing model, where a bunch of fairly small standalone "jobs" ran to perform limited functions. Instead today, we have event triggered micro-services. With all the same problems.