There are two things software developers hate, estimations and sketchy code. There are two things software developer create a lot: estimations and code. Here we can find a correlation, and I would argue a causation too: _Bad estimations lead to crazy code and this code will result in evaluations, which are only doable with writing said code. This is a death spiral.
Why dubious code is the root of failure
We know situations like this: You estimated how long you need for something and — it does not work out at all. You have a solution: Writing shady code is fast and creating technical debt is not a problem for you – but future-you, after the dead line. Unfortunately, you will not have time to bring you code into good shape because there will be: the next deadline.
The real, business issue is that maintenance and bug fixing will get more and more expensive, and the risk of a worst case failure occurring will rise continuously. You cannot explain that very well to the customer; therefore the deadlines will get tighter and tighter – until the project will get stress fractures. Projects can die because they are unmaintainable, or they stagnate because no one can muster the courage to update the system or add new features. (It will become a security issue too). That is why code quality is not just a problem for programmers; it is a business issue. Project managers, product owners, and CEOs should care about it.
Code quality will have a bearing on estimations
While estimating new tasks, it is common to ignore past dilettantism – after all, you do not know what it would have taken to write good code. Your estimations will not work out because they are based on old projects and fantasies about how much extra time you would have needed.
The only way to know how much time you need to write good code is to write it all the time. You have to carry the burden of defending quality against the deadline. That is why I propose, to do just that as much as possible. The project is done when your code does its job _and_ has sound quality.
The path to nicer code and qualified estimations is therefore evident, stick to quality even if it wrecks the project. After some time your estimations will not be based on unreasonable practices anymore.
Nonsolution: Everything is bad, let’s sell refactoring.
Refactoring is hard to sell, the customer will see it as following:
You build them a product. The product is shoddy. You want to fix it, and he has to pay for it. For his money will get nothing, but the same product, with nicer internals – he does not care about because he can’t see or understand them.
Imagine someone would build you a new house. While handing over the keys the builder explains to you that your brand new house is in need of serious and costly renovations and you have to pay for it. – Does that sound reasonable?
I cannot tell you how to sell something like that, and I’ve never seen it working out. You should consider writing better code instead. Pitching to the customer, that the quality of your work is bad sounds incompetent, doesn’t it?
Overkill unreasonable too
Just as a public service announcement: You have to have a positive cost-benefit ratio. There is no use for software that has the most excellent code but costs more than it earns. You might be in the position to tell people that the budget needed to create a solution, might be bigger than the value this feature can provide and that not building it is the rational decision – good luck and be brave!
Think about your future
Bad habits form slowly over time, writing bad code is a habit.
Many people like quick fixes and shoddy work, because it seems smart. However, doing things like these will form unprofessional behaviors. Writing good code is important for your reputation and career.