Dealing with technical debt and nearing release

Question

Say you have a project that is a tangled mess. No code structure and breaking one area breaks the entire thing. Fixing one area breaks another area. The closest you can fix things is writing the code that's almost like redoing the entire thing. But then, the release is in the next week.

Here's some facts that actually worsen the situation:

• There's very minimal testing. Makes breaking hard to find.
• The code has no structure. Imagine one app has everything in one file.
• No documentation. Very hard to replicate server requests when there's no documentation about the parameters to send, and what to expect.

What should one do to address this situation? The best thing to do is extend the project release, but I'm not the one who calls the shots. I did comment on the issue though.

Answer 1

Sometimes the best thing to do is do nothing.

Leave the refactoring until after the release. A week away from release, your number one priority should be finalising the current build. The only code changes should really be bugfixes.

Don't extend the release. Unreleased software doesn't sell.

Do schedule time specifically to address technical debt AFTER the release.

Do break down the technical debt into work items. This way you will get specific flaws in the code structure addressed.

Do set a time limit for addressing technical debt. Version 2 needs to be developed and good software probably won't hit its strides financially until around version 5.

The thing about software development is that imperfect software makes money. Infinitely more money than unreleased software. The purpose of software is to solve the customer's problems. The purpose is not to have a beautifully engineered masterpiece.

In summary, release the software on schedule and allocate time to fix the worst technical debt problems.