If you were added to a team with a horrible code base and an unhappy client, what steps would you take to fix everything?

I've seen projects that have been successful because they had talented people and good processes from the start, however I was just curious on how one could recover from a situation in which people did not have the foresight to establish good practices early on.

Any suggestions?

Comments

[𒎏Wii 🏳️‍⚧️]

That's a really complex question. Why is the code base bad? Was it because of the programmers, or management? Is the person responsible still around deciding things, or are they gone (possibly replaced by someone more competent)? Why is the client unhappy? Is support slow because of the bad codebase? Or is it because of who they are in contact with?

There's a lot of questions, and I'd say the first step is to answer all of them. Get a clear grasp of the problem, then decide where to start fixing it.

[Jen]

Nowadays tech leads are aware of tech debt. A lot of the time is a 'ship now, worry later'. SometImes there is no foresight, and devs just need to hack something together. It's not a case of the devs being unskilled but if time and cash is an issue, sometimes implementing good process is difficult.

Getting dropped into a project, I would first analyse what is actually making the code base 'horrible', identifying code smells, figuring out how to make it less horrible. is it just buggy? or is it a whole heap of spaghetti? Usually fixing it is a case of modularising, which can be taken in steps. And of course, steps can be prioritised.

and to see if I'm actually making the code any better, time to write some automated tests.

Recently Monzo (a new challenger bank in the UK who grew extremely quickly) did a refactathon. A good read! tldr, they deleted 100,000+ lines of code.

[kshitijmeets]

Been there twice, burnt to crisp once. Here is a practical take:

• Are you the Product owner/decision maker? If no read next point.
• Does the product owner/decision maker feel that good practices are important? If no, then don't bother. You are set up for failure in this endeavor.
• If the decision maker is positive about this then read next point.
• Are you the tech lead or are you at that position in the team where you can decide the process and practices?
• If no then go to point 1 and replace 'Product owner' with 'Tech lead'.
• If yes then start with some low hanging fruits. unit tests are one of them. Find something that can be introduced without too much disruption.
• If you are a junior member of the team, focus more of following best practices of software design in your part of the code. Keep you head down and learn as much as you can from both the good and bad parts of the code. You are not ready for battle yet.