Nice and beautiful systems aren't the job, but a system that will continue working in the future while still allowing people to keep adding features and that won't suffer massive security breaches really is. It sounds like the current system is one bad feature implementation away from hosing the database, one hardware fault away from no longer existing, and one interested hacker away from a complete compromise.

You are right and obviously good engineering practices are not incompatible with the company’s interests.

I was more reacting to OPs attitude, where he asks how to fix everything without even being clear if he is managing the team or officially in charge of the product.

I may be mistaken but the impression I have is that the management is perfectly happy with a bad system and expects the engineers to simply go along. This is then a management decision. It may blow up later and sink the business (or not, it can just hold for the lifetime of the product).

As far as OP is concerned, this situation would mean that he should probably leave the ship now. (As staying would probably result in 1. No marketable skill development (being stuck with a garbage codebase) 2. Burn-out has he takes on the Herculean task of cleaning it up. 3. Be blamed if something bad happens.

Usually nothing changes for me as a developer if shareholders get bigger returns on their investments. So I don't really care.

What I care about is the code quality because good code makes my job easier. I inherited the code, not the business.

Well it is the management’s job to make your work aligned with the company’s best interests.

It is possible that you’re already doing what you’re getting paid for. In that case you shouldn’t go out of your way to increase the company’s profits (and nobody expects you to).

(In my original post I didn’t say that as a developer you should code thinking of quarterly results, I just stated the obvious that you are employed for the shareholders to get money back)