he’s the boss, it’s his decision. And I agree with him. NEVER change code for the sake of changing it. If there is a valid reason for the change (say things perform below requirements as they are) things should change, but “I think it’s not pretty enough” is not a valid reason.
Your religious zeal (and that’s what it is at this stage, or appears to be) would cost money, introduce risk (every code change risks breaking the product, requiring more changes, more testing, more delays). That’s never a good thing.
Instead make notes, and pick up those changes when and if the affected parts of the application need to change anyway.

My manager has tight deadlines to meet.

Most do.

The current project I am working on is currently on schedule

Good. Keep it that way!

I’ve noticed a couple of quite significant areas in the code that are really badly written. (Bits of code get called two or three times, when they only need to be called once.)

If that’s not a major correctness or performance problem then it doesn’t sound that bad. Calling the same code twice unnecessarily is often better than calling it once and caching the result. I’ve seen lots of bugs due to faulty caching logic. But let’s take your word for it that this is bad code.

The problem is, as far as my manager is concerned, the program works. As he sees it, there’s no point making lengthy changes to code that will make us miss the release date, for no tangible improvement that he can see. He keeps saying “That’s not a priority. It’s working fine as it is.”

Your manager is correct. You’re in the business of delivering value to stakeholders, not in the code prettification business. If you can’t make an argument that making the code prettier delivers more value to stakeholders than hitting the release date then don’t make the argument.

Should I keep trying to persuade him?

No.

Should I just do what he suggests and leave it?

No.

You should rather attempt to convince your management to schedule a “code quality milestone” after the deadline has been met. When your deadlines have been met and you’re planning the next version the first thing you should do is schedule a post-release analysis that goes over in detail what went well and what went poorly. That includes analyzing risks to future success, risks such as poor quality code that was checked in with known problems in order to meet a deadline. Use the time put aside for the “quality milestone” to mitigate those risks. It will help if you can arrive in that meeting with an accurate list of problems you’d like to address.

The argument to make there is that by doing so, you help ensure that your manager will continue to meet deadlines in the future.

Here’s some points:

1. Every change causes more errors. Modifying complex code causes more errors than it can ever fix. Ideally you would write it once and never modify it. Adding new code is ok, but changing existing logic causes more errors. If the end result is a mess the first time you wrote it, think how bad it’ll be if you modify it without remembering all the rules that gave you the original mess.
2. Complex code always looks bad. The code is complicated for a reason. It encodes the important business logic, and that is always complex. All complex code looks like a mess to people who do not know the rules the code follows. Once the rules are known, it’s nice logical system that just works correctly. You’ll forget the rules (or worst, someone else wrote the code and you never had the rules), and you’ll start thinking the important business logic is a mess. Cleaning up such code is a big mistake.
3. Over time, business rules gets outdated. Now you have a huge mess, and half the rules encoded to your software are outdated. Is it already time to rewrite? Definitely NOT. Only way to get rid of business rules that are already encoded to software source code is by dumping the whole system. Otherwise you’ll end up with cascade failures where one missing piece of software activates failures in unrelated code that has worked fine for last 10 years.
4. Maintainance is difficult activity. Maintaining the mess takes skill. You need to know to all the business rules collected in last 10 years to make any modifications. Forget one of them and your change is causing more damage than it is fixing. Good plan is to insert new logic, but never modify old logic. Refactoring or rewriting is wrong way to approach the problem. You need to start writing working code, and never never rely on chance to fix it later; the chance will never appear. Once it’s encoded to code, it’s like concrete; it’s always there and breaking it is dangerous.

Many managers don’t understand the concept of “technical debt” which is exactly what you are trying to stop from building up.

The manager is correct when taken in the context of just this section you would like to fix, but this really becomes an issue when many sections degrade over time, and other developers come in and build on top of it.

Then a bug is discovered in part of the code, but only gets fixed in one section, not in the copy and pasted sections.

While you have not went live yet, there are other things that you need to keep in mind that the manage is probably thinking about.

Maybe this code rework will mean that a large testing phase needs to be repeated. There is also the possibility that you will introduce bugs into a previously working feature.

It’s your job to point these things out, but still the manager’s decision.

However, you should try to make changes to you development process to avoid these problems in the future.

1. Identify the repeated problems and train the all developers on a prefered method. Everyone isn’t going to get this right the first time, so be prepared to catch them in a code review. This way, you can take the time to make the change before a manager knows the code is working well enough/goes on to further testing.
2. Start factoring #1 into your estimates. Your team will improve over time, but you better manage expectations upfront.

Hopefully your deadlines were established based on how long the develpers thought it would take to build and not some other arbitrary method. Some developers feel like they’re the bearer of bad news if they make lengthy project estimates, so they avoid it by being overly optimistic.

This is subjective question, and here is my viewpoint.

YOU SHOULD try to persuade him. Fact that you wrote this question here answers that.
How hard you should try is different question..

Think about different parts of system:

• How far into development of that module you are?
• How likely is that same module will be significantly changed in future (spec. changes).
• Is public interface of module changing?

Just ask yourself those questions and make your own pros/cons.

For example if module is almost finished and likely to be changed after release, I just leave refactoring for later. But if it is in early stage, and specifications are not likely to change, refactor ASAP. Because specs WILL change, and after not looking at messy code in two years you will have hard time implementing new spec. changes. It might be so bad that you decide to write module from scratch,and just use some parts of code from earlier version of module.

There are some trick that can convince manager to let you refactor.

• Find a bug in existing code. You can spend time refactoring while fixing bug.

No, you shouldn’t. Deadlines are more important than tidying code, because you probably have no idea why the deadline was set in the first place. Maybe you have to finish before your competitor, who would steal your customers. Or some laws are coming into force. Or it’s just getting too expensive for your starving CIO. Or…

If you think releasing it would be a great risk, then explain it to your manager. Valid reasons are: customer data could be lost, the company’s reputation will suffer or something else what would have a negative impact on the company. But your manager has to ponder risks and opportunities, and he has to decide if it’s worth to move the deadline.

But ask your manager to schedule some extra ressources next time, so that the software won’t become a big, unmaintainable monolith. Then your manager can keep his deadline and you will have enough time to create a fine piece of software.

Whatever you do, please don’t give managers a reason to think of programmers as people in ivory-towers who don’t know anything about business.

Update because I read that it is a newly-written application:

Your first priority should be to do a root cause analysis to find out why that bad code was written in the first place. Did requirements change? Is one of the programmers not skilled enough? Does the deadline provoke a send-and-forget attitude?

Problems in code can create impractical timelines for maintenance in the future, especially if the problems aren’t properly documented with comments in the code.

Most managers have enough of a technical understanding to allow them to perform their job, but they won’t know how to code, nor with they understand how problems can impact timelines in the future.

I would approach your manager in writing and outline to them what can (and likely will) happen down the road by allowing the issues to remain untouched and unresolved. This can include timelines that will be affected when modifying it in the future for updates, poor performance of the application (resulting in poor user satisfaction), etc. When they understand the impact of the problems and make their decision, accept it and move on. At this point you will have done your job as a credible and reliable programmer (with written proof that you have), and now the ball is in their court for taking responsibility for any problems associated with the issue that you have outlined.