> Bad code that ships is better than good code that doesn't. Sometimes, but not always. The bad code that ships however always feels better and gives the feeli

> Bad code that ships is better than good code that doesn't. Sometimes, but not always. The bad code that ships however always feels better and gives the feeling that progress is being made. That works fine until a wall is hit and things have to be rewritten or worse hacks have to be added. That ends up taking more time than the original solution, but guess what... no one is going to bring that up. That means the correct solution never has a chance to get the points it earned to be weighted more highly next time a decision of correctness vs speed is made. There are pre-built frameworks for handling the common "ship the bad code, never say it's so bad it's a net loss, and just iterate on the crap on top of crap you have" so that all levels of the organization feel more comfortable. > With all that said, I do wish that we had better software, and that correctness mattered more. It can't matter until technical debt is analyzed on a meaningful time scale and actual observations happen, rather than what amounts to making things seem like they're going smoothly.