You wrote "they" and "them". Who is that? Who is making the go/no go decision? Is your boss involved?

Is there really no way to meet the deadline? Or is it a matter of it will take longer because you want to fix everything up? Based on what you wrote, it sounds more like the latter. Discuss both options with the people who get to make the decisions.

@Asperger - so it sounds like you went ahead without approval and spent days trying to rewrite things to meet your preferences, and now you can't deliver on the required deadline. That's unfortunate. Hopefully, they can extend the deadline and you can meet it. Make sure you understand specifically what you must do and how long you have to do it. Then stick to the plan, even if it means compromising your personal standards.

You say, you could finish the project by rewriting everything in 5 days? Are you sure about this? And is the deadline more than 5 days away? Can you just rewrite it and, label your refactorings "minor adjustments" and nobody is any wiser?

I've written horrible code and learned a lot since then. One time, an otherwise good dev didn't like what I wrote, which I knew to be clean and correct. He argued passionately, like you, then rewrote all of it, without any authorization. Please make sure you're not being ThatGuy.

@donjuedo Wow, that was phrased gently. IMHO there's a 95% chance we'll see an upcoming Q "How to work with prima donna developer?" with suspiciously familiar details.

It sounds like the existing implementation won't work in the long run (due to it being an unmaintainable mess) and the rewrite won't work in the short run (due to their not being enough time to finish it before the deadline). Assuming the deadline isn't negotiable, you'll probably need to get the existing implementation working well enough to ship, and also work on the rewrite so that you'll have a path forward for version 1.1 and later. But shipping something usable before the deadling is probably the higher priority.

Rewriting is almost never the answer in a business context. While it might be less efficient in the long run, the best approach is probably to isolate only the parts of the system that affect your current, immediate goals and make those work well. Good software is written by applying good principles to arbitrary code, not necessarily by starting with perfect code from the get-go.

Usually everybody agrees to rewrites if they make sense and improve the result. Especially if “everybody” does not have to do the work (but the proposer has). The fact that this is not the case in your situation does mean something, hard to say what it is in your specific situation. Maybe you can elaborate a bit on their reaction to faster and nicer Frontend?

@DanielLittlewood You are 100% correct, I suspect your comment should be an answer, because it may give good advice on how the OP can proceed not just with meeting this deadline, but also other deadlines in the future.

I'm a firm believer in "boxing". If something is awful code, put it in a wrapper that conforms to the good-code standard. Basically a black-box where you know it'll work and won't touch anything else. Then you can write a new version of that box later and replace the crap code wholesale. Maybe that'd work here, maybe not. It's easier to copy/paste code into a box than it is to refactor it

You wasted two days rebuilding what already existed just to prove a point. How did that help you achieve your deadline? These are questions your manager will be asking.

We've been here before: joelonsoftware.com/2000/04/06/things-you-should-never-do-par‌​t-i

"I literally recreated it with 80% of all the required functionality in only 2 days" So, it will take at least 8 more days to get to 100%? Quick rewrites are deceitful. Some features require ugly codes and breaking "nice" rules to work well. Do you know how to rewrite every feature without ugly side-effects, hard-coupling, and completely DRY? Maybe you can, maybe it is all simple code. I'm just pointing out that you make big claims, perhaps bigger than you realize.

Why do you keep mentioning "with unittests" as if they lengthed development time? The whole point of unittests is that you save time by testing early and often and avoiding debugging weird bugs or finding bugs after deployment... so time spent writing unittests should be worth 5x the time you'd spend in other tasks if you hadn't written them... Then again, if you don't know how to unittest you can probably end up spending more time writing tests than what they save you but if that's the case for you than you're probably as bad at unittests as this other backend dev at frontend...

Keep in mind that, even if everything you say is correct, how you present it can still be incredibly rude. And that will sour any attempts you make to push the idea forward, regardless of the merit of that idea.

"I could easily solve the problem rewriting all this garbage in 5 days". Every developer has gone through this at some point. Nobody who tries ever succeeds.

@GregoryCurrie Thank you - I wrote one, but now realise I don't have sufficient rep.