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.

Present - Photo by Kira auf der Heide on Unsplash

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.

Some examples

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.

Audit your code as the first thing

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:

  • Code legibility
  • Overall code quality
  • Frameworks, libraries and versions
  • Red flags
  • Style guides (or lack thereof)
  • Documentation status
  • Security basics

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.

What if you're trapped?

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:

  • Code legibility
  • Overall code quality
  • Frameworks, libraries and versions
  • Red flags
  • Style guides (or lack thereof)
  • Documentation status
  • Security basics
  • Performance issues
  • Deploy systems
  • Third-party dependencies
  • Code completeness
  • Integrations: integrity and documentation thereof
  • Code logic distribution
  • Database connections and status of its content

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:

  • Better safe than sorry: You don't want to let them know of the problem after they happen. It's always better to prevent them.
  • Prove your expertise: This is a pro move, and it will show the client that you're knowledgeable and know your stuff technically.
  • Builds trust: It shows that you care. You demonstrate that you're worried about the future of the project and the potential impact these problems can have on the business.
  • Buys you time: Whenever you will find that you need more time to do "that easy thing" because the codebase is rubbish, you can circle back to this list to the client to justify it.
  • Upselling: Some things will have to be fixed so maybe you find yourself with a bigger contract as a result of the audit.

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.

Àlex Rodríguez Bacardit

Àlex Rodríguez Bacardit

Desarrollador convertido al lado oscuro: desarrollo de negocio. Experto en crear problemas y luego solucionarlos, se encarga del crecimiento y estrategia. Récord Guinness por completar Day of the Tentacle en tres horas.

comments powered by Disqus

Estás a un paso de conocer a tu mejor socio.