You express a lot of true ideas in regard to the life of a mainframe programmer! Cobol was the programming language of the masses back then. I used to write a lot of Pl/i/Asm at IBM. With Pl/i, we could develop external subroutines that were reusable and were linked into the manager module. So, we could unit test each subroutine with a “main” stub. After that, we hooked the validated subroutines into the actual mainline and performed integration test. Pl/i, with pointers and dynamic memory allocation, was the Cadillac of programing languages. Only an elite few mastered this language. And ASM(BAL) was used for the hot spots, in terms of performance, in a Pl/i application system.

I was to use a language that is younger than I am!

Endeavor sucks and it is one of those 80s tools I was talking about! Worked with Endeavor as late as a year ago. It one bit of the solution. On the mainframe, most bits are still missing.

We can keep these old, degrading systems in the ‘air’, but the backlogs (often hidden) and the time it takes to get a change through the system both become longer & longer.

It’s been said that > 95% of all problems are management problems. An organization that gets itself into this state has only its management to blame.

Organizations in this technological state tend to have other management problems too. Arse covering, blame games, miles of red tape, the list goes on. These all create wasted time/labour & looooong feedback cycles.

The doers on the floor have to live with the consequences.

What I get sick of is finding broken corner cases. Writing a fix. Writing a detailed test setup for the Test team. You know that once the fix is done, that the test case & all that supporting work will never get read or used again (due to time/labour costs, because its not been automated). Some future change could break it again and no one will know until the system breaks or the database is corrupted or a customer complains or …

The result of any design process is a set of unvalidated design decisions.

The other half of the process is design validation. In other engineering discipline, it’s call analysis. IT uses this term for something else. Until they develop mathematical proof methods that are computationally cheap. The best validation process is testing. The cheapest (cost per individual test execution) testing system is an automated one.

Mocking is something that can greatly reduce time costs. This means the revalidation of a design can be done more often. The closer the revalidation is to the point of design change, the better & faster the design feedback loop works.

I, as a professional, have a responsibility to the shareholders/tax payers (and other stake holders) to ensure that the money invested in the development process, is invested in a best way possible. That means looking a both the short & longer term returns that can be gained from the different ways of doing me job.

Just watch the backlog grow and the code base degrade! Of course any organization, like that, that is still alive today, is in a monopoly situation. Like big govt departments and big oil.

Unless your in a monopoly (natural or unnatural), if you don’t automate a much as possible, someone (be it down the street, in the next state or India), is going to eat your lunch at some stage.