It kind of depends on the company and the projects at hand. I've been in a similar situation and still am now to a fair degree. Back when we started the projects there were no guidelines or clear rules and definition set: "There are X developers, this is what needs to be in production in a month". Hardly any specification just a vague explanation of what was needed. Which might have been fine, but half of those developers were as bad as they could get. And even spending 7 days a week at the office was not enough. I mean no one could realistically finish what they were doing and then go back to cleaning after the others. But, 30 days later we were in production(till this day, I have no idea how).
The biggest problem was that most of the bad developers were located in a country, where once you are past your test period, and you are at work at 8, no one can touch you. Meaning that for years, they were doing every anti-pattern known in the books, and someone cleaning up after them(in most cases me). And in those conditions you are left with no choice but to... Cut corners... Eventually we managed to pressure all of them to quit. Keep in mind, there were entire releases where I've personally had to re-do everything they had done for that release because it would take less time than it would take me to tell them what they have done wrong or why. And they were perfectly happy with that. All while every deadline was approaching fast. Now with them gone, things are improving, though we still spend countless amounts of time to clear the roads from what they left behind while still having to build on top. Which, sadly, is a slow and painful process.
My advise - do the best you can do to your ability, even if it means cutting corners for the time being. Once the water has set, things will start going back to normal(but that could take a lot of time). This has to do with the lead developer(which we didn't even have at the start, and one was appointed much later). Eventually he quit so... I was next in line for better or worse...
So a 3 things you need to figure out:
1. Lead developer - are they pedantic, strict and do they go over stuff when they have free time and fix/optimize things? If they do re-factor or even rebuild entire chunks of the application with the intention to improve it, then sit back and relax. Things will eventually start falling into place(see my following points). Go through something big in the project they have developed on their own with sufficient amount of time at hand? Is it clean, well structured, documented and organized or is it just "working". Do they write documentation when they can or do they just kick the can down the road(again, stressing on "sufficient time")? If it is effectively good code, you are on the right path. Granted that the rest of the team has the will to learn and improve. Tl;dr - follow the leader, something which has been instrumental for many of the developers I've worked with. Eventually they will start mimicking the leader's behavior. Your best course of action is to give him/her enough space to be able to clear things out - you know - flatten the curve.
2. Tests, while good, are not always a clear indicator. Sometimes people take tests as ground truth and as long as a test passes, they will call it a day. In addition, some systems are way too complex for automated tests. I have such an example, I've worked out the math: you need a 124! (yes, factorial) to cover all possible scenarios. And counting... Good luck with that. So yes, no tests, just making sure that there's a way to restore things if something goes wrong.
3. Company infrastructure - some companies are incredibly strict and conservative, meaning that developers end up having to spend ridiculous amounts of time trying to get around firewalls, rules and regulations. Which, as you can imagine, takes a lot of time and a lot of effort to break out of. But with the adequate amount of will and time that's not impossible.
The biggest problem was that most of the bad developers were located in a country, where once you are past your test period, and you are at work at 8, no one can touch you. Meaning that for years, they were doing every anti-pattern known in the books, and someone cleaning up after them(in most cases me). And in those conditions you are left with no choice but to... Cut corners... Eventually we managed to pressure all of them to quit. Keep in mind, there were entire releases where I've personally had to re-do everything they had done for that release because it would take less time than it would take me to tell them what they have done wrong or why. And they were perfectly happy with that. All while every deadline was approaching fast. Now with them gone, things are improving, though we still spend countless amounts of time to clear the roads from what they left behind while still having to build on top. Which, sadly, is a slow and painful process.
My advise - do the best you can do to your ability, even if it means cutting corners for the time being. Once the water has set, things will start going back to normal(but that could take a lot of time). This has to do with the lead developer(which we didn't even have at the start, and one was appointed much later). Eventually he quit so... I was next in line for better or worse...
So a 3 things you need to figure out:
1. Lead developer - are they pedantic, strict and do they go over stuff when they have free time and fix/optimize things? If they do re-factor or even rebuild entire chunks of the application with the intention to improve it, then sit back and relax. Things will eventually start falling into place(see my following points). Go through something big in the project they have developed on their own with sufficient amount of time at hand? Is it clean, well structured, documented and organized or is it just "working". Do they write documentation when they can or do they just kick the can down the road(again, stressing on "sufficient time")? If it is effectively good code, you are on the right path. Granted that the rest of the team has the will to learn and improve. Tl;dr - follow the leader, something which has been instrumental for many of the developers I've worked with. Eventually they will start mimicking the leader's behavior. Your best course of action is to give him/her enough space to be able to clear things out - you know - flatten the curve.
2. Tests, while good, are not always a clear indicator. Sometimes people take tests as ground truth and as long as a test passes, they will call it a day. In addition, some systems are way too complex for automated tests. I have such an example, I've worked out the math: you need a 124! (yes, factorial) to cover all possible scenarios. And counting... Good luck with that. So yes, no tests, just making sure that there's a way to restore things if something goes wrong.
3. Company infrastructure - some companies are incredibly strict and conservative, meaning that developers end up having to spend ridiculous amounts of time trying to get around firewalls, rules and regulations. Which, as you can imagine, takes a lot of time and a lot of effort to break out of. But with the adequate amount of will and time that's not impossible.