How Do You Deal With Outdated Code?

How Do You Deal With Outdated Code?

Sometimes you gotta do what you gotta do to survive in this competitive industry. Any freelancer or developer under pressure knows that it is better to start a new project from scratch.

Working with a project that has an ancient code with a lot of issues is more trouble than it's worth. And, sometimes, the client will not pay for your extra time spent sorting through a legacy mess.

You'll run into default problems, like missing deadlines. Or features that grow into a separated project over time & budget, a client that can't pay for code quality, code that won't be tested appropriately, etc.

It should work, but with a few "small" add-ons that will force you to redo your DB architecture.

We all know how hard it is to support an old code. It's always easier to start from scratch and spend a lot of time while building complex and custom solutions.

I'll say it again and again, you or your team should take responsibility for project competition. What steps should you take that will simplify your work and help you to **avoid**a bad experience? Not an easy question, I admit.

But it is necessary to mention that we all should understand that the market will dictate terms on how to deal with the old codebase.

Markets and Leadership Will Guide Us

Depending on the market, development speed can vary. A complex fintech project will be pretty hard to update and support.

Security, and working with financial transactions are not simple. This is why banks and health tech companiesusually have huge teams.

It is much easier to update "an ordinary dev project". Yes, the project type will reflect the costs of the upgrade.

Documentation should be prepared and approved by executors and decision-makers. No, you can't start coding without it. Even if everyone knows what he or she is doing. Would you undergo surgery without having a thorough examination?

(Hint: NO, you wouldn't; and this is why someone should play a bad cop with a pessimistic attitude. It's part of a leadership role.)

It can't be a manager or developer that doesn't give a f. I mean, besides shareholders, someone in your team should be your "product manager."

And don't forget to provide him with a bonus. If you don't, you're just stupid.

Documentation Must Be Created!

Not just for fanciness. It should be your main document, a roadmap thateveryone will always have at hand and can navigate it pretty quickly.

It's easy to test if you have created a great resource: people have stopped asking questionsverbally. I'm not against that, but it is always better to keep everything in written form.

Everything can be missing after having a quick chat. And it will be gone in 1 day.

Do you know the Sydney tourist attraction, the Opera House?

This project is a playbook story for project managers. It was a PM disaster.

They spent three times the budget and missed all their deadlines.

I think software developers may have been involved, because we are pretty good at missing our deadlines.

Are you sure that your clients or shareholders are ready to deal with the same kind of situation? Usually, they don't, and they __WILL Blame You __even if your intentions were good. So be careful with the old code that has a lot of tech debt.

There is a reason why it is better to fix it during the development phase, not after.