Today I'm talking about tech debt. (I initially had a longer intro, but I wasn't sure you'd get it. Sorry.)
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.
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.
Market and Leadership Will Guide Us
Depending on 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 healthtech companies usually have huge teams.
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 that everyone 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 questions verbally. I'm not against that, but it is always better to keep everything in a written form.
If you think that something is not covered in your project, then don't think you are better than others. This attitude will help you avoid any further problems.
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. This is why I'm using the CodeClimate Quality tool for my small code projects. It shows me how bad I'm at coding.
