A programmers answer: No
A salesman answer: Yes
A PM: Do what you can but meet the deadline.
My answer: No - tl;dr If you find yourself in this spot then it's poor planning. Additionally, 90% of deadlines, in any sector, are missed anyway.
Final thought - This question doesn't just apply to code - it's a question that applies to any sector. The biggest battle any company has is not it's competitors/etc, it's the internal battle of Cost vs Quality vs Time.
Having access to a modern IDE these days makes it possible to write clean code and extract things into proper names in seconds. I don't get what you mean by "unthought-through code". Any code that works is code that you understand and think about. In my experience, unless is a trivial spec you implement, the mor disorganized you are, the later you get to deliver. If there are just a few lines of code, there is no reason not to have them clean. If there is a larger portion of code, if you do not start by keeping it clean, you will only be slower, because you will not be able to reason about you code you just wrote. I do get the fact that code may not be perfect. There may be duplication. There may not be the best possible architecture on the first try. But code has to be clean and it should be easy to reason about, whatever the deadline may be. Writing code takes the time that it takes. But never the time to write code is the most important part. You spend over 80% of your time reading it.
Probably, if I was forced to, but not without explaining to whomever was requesting it that the code is likely going to be fragile and have the possibility of breaking under certain untested conditions. I would definitely clean it up later.
I had a boss who was fond of saying: You want it bad? You'll get it bad.
One of my favorite quotes:
If you don't have time to do it right, when will you have time to do it over?
Another relevant quote:
If you don't do it the right way now, it'll never be what it should be — and it's there forever.
I reject the premise of having had an unreasonable deadline. I would avoid situations where a hard deadline forces the progress of a project. If it's not open heart surgery then it's probably ok to take a few extra days to get things done right. If you are in a job / situation where it's do or die on a deadline, then the problem is not bad code but a bad work environment and I encourage you to find something new.
Yes if it does the job as requested without any trouble. I've done that for a client; first we finished the code and deliver it, then we cleaned it and optimized on the weekend.
First of all, why terrible, messy etc code it's faster to write than good code? Probably you can write good code in the same time, this good code maybe will be not the best in terms of performance but that's all. My recommendation is: try to do your best effort to write good code even when you are in a hurry.
That's a very broad description :) I suspect I agree with the principle you're driving towards; but it's a different decision at different points in the dev cycle.
A months-long death march of slinging bad code is a bad idea, but the day before launch, I'll allow non-reusable, gaffa-taped solutions if they touch less code than the full fix. Why? Because major refactors open up a bigger risk surface than a contained/targeted hack. The small hack should also be quicker, leaving more time for peer review and testing.
So like most things in dev... It Depends.
Also there's an assumption that the team's writing good code the rest of the time, writing tests that will catch any major breakages and so on. If process is bad all the time, it barely matters what happens under pressure. You really want process to be lightweight, purposeful and second nature enough that people can stick to it even under pressure.
No. This would be inviting huge trouble in future if you had to maintain the project.
Define terrible.
If said terrible code worked and meant the deadline was meant, depending on the situation, it might be unavoidable. I am not ashamed to admit I have been in this situation. If a company can't manage their timelines appropriately, promise clients unrealistic timelines or worse: underquote to pocket the cash, then what is the alternative?
I think we have all been in this situation before:
Boss/Project manager: the project is due in two weeks, you're a smart guy and John will help you. This is a great client and we really want to woo them. This will just be a one time thing, in future we will properly plan for projects like this.
Developer: Uh.. I don't think two weeks is achievable. If no changes are made and I get finalised designs, then we might be able to get it done.
Designer: I just have a few design tweaks I want to make, nothing major. I have just redesigned this page, changed the font and oh, we need to make it look good on small, medium and large screens as well.
Before you know it, you're leaving at 10pm every night. You're coming in at 7am and you're also working weekends to get the work done. Even if things aren't being changed (which in many situations, they are because others are under the pump as well), you'll be putting in serious overtime.
I personally know of companies who factor in overtime into their estimates. They deliberately promise delivery dates that cannot be met without overtime. It's shady, but a lot of companies do it. It's amazing what being in fear of losing your job can do. Sometimes nothing you say or do can change that, except finding somewhere else to work.
Sometimes even when you speak up, nothing changes because the decision has already been made without consulting you first, the client has been told a date already. If you work for a company that do client work like a studio that does Wordpress websites or apps, this situation is something you will encounter, some places more than others.
If the "terrible code" works fine, then yes. Automated tests will play a key role in this case. If you have a good architecture and can "sandbox" your workaround, keeping it from spreading, the risks of doing this might be less than missing the deadline.
It's very importat that you do not create dependencies on code you know is bad. After the deadline you should come back and cleanup the mess (if at all possible).
It's an illusion to think you will always write good code. Actually, for me, good code is the one you can improve over time. But again, for this, you have to write tests.
If it is my own code or no one else will be working on it in the near future; if it is bug free (aka: the requested functionality is in place and the user may navigate through the process unhindered); if it is for a prototype or pilot run and I am driving for the demo... All that said: I make the deadline, get paid and improve the code ASAP after first release. Else NEVER. That said... our definitions of terrible-messy-unthought-through-code might differ
If I'm writing it and I can write it bug-free and missing the deadline would cost me money, then yes. You can always clean it up after the deadline and mark it as a performance improvement / refactoring.
tl;dr: NO. You will only introduce bugs. So even if you meet your deadline, no one will be happy with your solution.
What you should do is talk to your boss or project leader/master, tell them about the situation; work out a plan to make the best out of the situation.
Manny Henri
Coding. App & Web Dev. Author for @lynda. Mentor for @thinkful. Contributor for @tutsplus. Love @reactjs ecosystem.
That's part of our daily challenge but rushing bad code is just part of all the issues on the web and applications. Like many others mentioned it's better to limit the release plan than to release anything with potential security holes and buggy functions.