As a developer in a very small team (we are two...) without senior devs to help us, I know the thing that helped us a lot was integrating quality concerns into our workflow.
We test A LOT what we do. I consider myself to be very unreliable, so I triple-check everything I do and I force my coworker to do so: we unit test many things, and integration-test everything (with Selenium for example).
We now are QA+Dev people and even if it doubles the time we spend on features, at least the application works as expected when released vs what we did before: rushing to get as many crappy features to show our boss as possible, without checking regressions or edge cases and eventually earning the reputation of bad developers :D
Edit: Better answer with a task list you could try
Without knowing much about what they exactly do wrong and the size of the team, here is what I would do in such a situation, based on my own experience with the same situation
(when I arrived in my company fresh out of college, all our products were borderline crappy, with bugs everywhere, bugfixes creating more bugs than before,
devs not caring, boss burned out, everyone leaving out of despair):
- Start integrating quality concerns into the development process: the devs must be committed to produce quality code, and they HAVE TO stop thinking their job is coding. Their job is 1 third specification/thinking, 1 third coding,
1 third testing.
- Make them unit test a lot of what they code, and you can gamify (always work with devs) this by measuring test coverage (even if it has downsides which we can discuss about later): you have a direct quality metric
- Make them understand the end-user constraints first: they need to know what has to happen and not interpret too much on vague descriptions made by higher ups (a huge problem in our team that we try to solve with user stories)
- Make them (or others) test the code from a "client standpoint", either via automating the user or having a guy doing checklists (very boring, automation is much better if possible). That will show them immediately how
crappy their code is: the whole app simply doesn't work as intended.
- Make them do peer review: each dev is responsible for the code of another one, and has to check the new stuff from times to times: we use Atlassian Crucible/Fisheye for that and it works very well
- Use a lot of gamification metrics to give grades to the code, Sonar is a very good tool for this. For example in my team we have a grade of "76 days of technical debt" which means that for our code to be perfect we need
to spend around 76 days correcting it. Of course it's only technical and it's a very vague grade but at least they have a grade. They know if they do better than the last time or not, and it becomes a game to try and
lower the "debt". It give you a lot of other such metrics you can try to beat too.
- Try to make them build "end user test" documentation, that THEY will play with the end user (sorry I totally lack the english words to describe it). That will make them responsible and shameful if something doesn't work. (I work after hours when I disappoint a client with an unexpected bug vs I don't care too much if my boss just goes around and tell me "don't forget to fix this weird thing someone might one day notice")
The thing about some devs is that they think code is their job. It's because there are rhetorics everywhere about talented developers, elite programming languages, skills etc. While in reality a dev is not much more than a factory
worker having to assemble pieces together. The complexity of the assembly phase is impossible to perfectly predetermine and that's where "skills" is involved, but we have to understand we do industry stuff that need
to be reused, maintained, read, monitored, scrapped etc, just like in a factory (don't tell them that xD).
The quality of the work we do is much more important than finishing soon, coding like a star, learning something new. So in my very humble opinion, they lack quality concerns, and it's not so hard to make them understand. It
took me 6 months to totally change the way we work, from vague oral specification to dynamic written specs transformed into tests and code. And now we even sell our products :D