Is 'It Works' good enough?

Having programmed in mainframe environments (OS3x0 and z/OS) for decades, I too have seen tons of poor code. We have inherited the sins of our ancestors. Bear in mind that, in the mainframe universe, you're probably looking at lots of older code written by people who were not raised to code according to modern, contemporary principles (I saw some COBOL about two years ago, written by a young, Indian consultant that was a stunning example of pristinely well-structured and profoundly correct thinking and implementation...proper, formal education counts!). Further, you're working for management who is similarly ignorant (may be some of the same people who wrote the garbage you're having to support) and has to allocate resources in a fairly cost-constrained manner. Neither the people who wrote the code nor those responsible for its management (originally or currently) are likely well-acquainted with the higher costs of maintenance that result from bad programming practice. It's an ugly combination of circumstances.

You will best "wage war" by helping your peers to evolve by mentoring them in best practices. Provide examples of things you encounter and repair and offer analysis of why the old way was "evil" and your reformation is "virtuous."

You can seduce management buy-in that training and enforcement of best practices in design and implementation are valuable by providing proof that bad programming costs more money to maintain. There's a huge amount of literature about this. Clue your executive management.

Encourage code reviews for changes and new development and enforce your standards as vigorously as you are safe to do. It ain't gonna change fast or easy, but it is "the good fight," and best serves the interests of your stakeholders (as well as reducing the number of painful 3am on-call wake-up calls you receive).

Yes.

I cleanup code whenever I touch a program that I didn't initiate. Unchecked return codes, variables that are no longer used, horrible indenting (leading to lack of readability), etc.

I recently (well almost a year ago) added tooltip support to a UNIX GUI application. That was fun, but I had to clean up all the code and go through it all to make sure I understood it, since there was little to no comments.

There have also been times where I've rewritten code based upon what the original program does so that it is more up to date. This example was converting a COBOL program into one that used C++ and the results were astounding because there was so much extra crap in the old COBOL program that wasn't used anymore (literally never referenced).

Likewise, I've converted time consuming mundane chores to very fast. One such instance was someone downloaded a report from the mainframe, brought it into Excel and ran a macro or two on the report, then MANUALLY deleted unnecessary items, then ran another macro or two, and exported it as a file. This process took someone that was familiar with it about 2 hours to run. I wrote a C++ program that did the exact same thing that took only 4 minutes to run (and most of that was due to the person having to read the screen).

Well by CompTIA that isn't good enough. A lot of places are getting more and more strict on how things are done but i feel you pain. We hired a third party to design a skin for a customers account on our online store front but it doesn't work how i need it to. Will they fix it, hell no cause according to them it works to what my coworker wanted. Well I'm the one who has to deal with it she was just there to give suggestions. So now i have to teach myself HTML so i can make a skin that works right.

It might be fine in the short term, but having unmaintainable code _will_ eventually come back to bite them.