Audit the code you inherit
Diario del capitán, fecha estelar d475.y39/AB
How many times have you - as an agency or freelancer - inherited code from a previous provider or another team? How many times have you been blamed for things that were not your fault? You can avoid it, if you follow our advice.
One of the most frequent kinds of projects we get at MarsBased is to take over existing platforms/apps to continue evolving them or simply maintain them. I can't quantify this, but it's around 50% of the projects we sell.
In a lot of cases, the client wants to replace their provider for whatever reason. Maybe they weren't good enough, they had to shut down the company, or stopped giving service altogether. Whatever the reason, one thing is guaranteed: never have we encountered a project where we've had support from the previous provider after we have inherited the code. In most cases, the client is not on good terms with them, or the whole process of replacing them takes the previous provider by surprise.
It might also be the case that the client's previous team, or individual contributors, left the company, and with them went the know-how of the project. It might also be that the client has acquired another company/project and needs to be integrated with their current techstack.
Whatever the case may be, there's one thing that you - as an agency or freelancer - can do to prevent falling prey to someone else's mistakes or wrongdoings and being blamed for them.
It is very common that after a few days of working on the project, you discover that it's in a really bad state: hardcoded passwords, no style guides have been followed, no clear distinction between business logic and views, unused libraries everywhere and more. What can you do?
Worse still, you decide to soldier on and start developing because the client is pushing for new functionalities. However, with every change you introduce to the system, you break something else, because the codebase had no test coverage whatsoever.
Even if you circumvent these problems, there'll come a day in which all will break. There'll be a security exploit, the app will find its scalability limits or you will be caught in a dead-end road because it's impossible to fix anything else and the only way out is a full rewrite.
It's too late to go back to the client and say this was broken from the beginning.
Why? Because you should have told them right at the start of the project.
We are always adamant about auditing the code before we even sign the project. In most cases, the client will give you access to it to check it out, provided you sign an NDA, which is fine by us. We typically don't sign NDAs, but getting bad code can be as bad as being trapped by an NDA.
Usually, our CTO or our tech leads take a look at the code and report basic findings on the status of the codebase:
We typically don't invest over half a day or an entire day unless the platform is very large. In a few hours, we can see whether it's really bad or acceptable. In very rare cases, we will find really good code, but the truth is, if they had been good developers in the first place, maybe they wouldn't have been replaced. Just guessing!
Sometimes, however, we can't see the code prior to signing the contract. That is the case with most large corporations. First, you need to become their vendor, and once you've completed their procurement processes and you're finally appointed as a vendor for one of their projects, you will get access to the code... but is it too late?
Not really: if you have explained that you will do the audit after you start the project, you are in a good position. We include one slide on our sales proposals to explain this, and typically, it's the first thing we do after setting up the environments.
In this less-than-ideal situation where you couldn't see the code but had to sign the contract, you have to audit the code as soon as possible. In this case, we go even further, spending twice as much time to find things that can create problems down the line.
This time, in addition to the above, we inspect the code for more findings:
After the inspection, we let the client know what we've found. If it's good enough, it'll be reassuring for them to know and it will also be helpful to us because we will be able to develop more quickly and safely.
In the case of finding a lot of issues, we send the report as soon as possible and schedule a call with them to let them know the implications derived from bad code or architecture.
Even though it looks risky, it's fundamental to your current and future relationship with the client for the following reasons:
All in all, it's a very good return for a decent time investment at the beginning of the project and it's helped us pretty often to get in better places and to build trust more rapidly with clients.
While code refactoring is cool and appealing, it's not the right choice always.
Leer el artículo
Some tips on improving self-confidence when developing software projects. Being self-confident helps you writing better code and focusing on what really matters.
Leer el artículo
Announcing our new corporate logos, slogan, the Spanish version of the site and our newsletter.
Leer el artículo