It's the dream of every engineer to get to make something that doesn't suck, right? But the 80/20 rule applies. Getting through that last 20% that is suboptimal is 80% of the work. Every hour you spend polishing your way to perfection is an hour you don't spend adding new features or creating new products. Every bug fix is paid for with opportunity cost - at a very high compound interest rate, if you're in a startup.
I've come to the conclusion that if your code doesn't kinda suck, you're doing something wrong. You're wasting effort. Actually, I came to a much harsher conclusion than that - I've concluded that all software sucks. That all software hovers near the line between "barely works" and "doesn't work". Why? Because by the time you get to feature-complete, if it still works, it's so riddled with compromise and bad decisions that you never want to look at that code again. You want to start something fresh and new, and THIS time, you won't make all those stupid mistakes! This time, it won't suck!
I think it's possible to write good software, but I agree that it's difficult to do at a startup. At the very least, there are kinds of software (aerospace and medical software for example) where hovering between "barely works" and "doesn't work" isn't acceptable, and the people responsible found ways to improve their software beyond that point.
It's not really making software that more than barely works... it's changing the definition of "barely works". I've spent most of my career in banking and health care, stuff under heavy regulation. The regulations become part of the requirements. And within those bounds, banking and health care software barely work. Avionic software barely works. The software that keeps your pacemaker going? Barely works.
Remember, a pacemaker that doesn't work 1% of the time doesn't work. Specs are different.
