[kostyal]

I always liked this quote by Jamie Zawinski, from Coders at Work

"I know it’s kind of a cliché but it comes back to worse is better. If you spend the time to build the perfect framework…release 1.0 is going to take you three years to ship and your competitor is going to ship their 1.0 in six months and now you’re out of the game. You never shipped your 1.0 because someone else ate your lunch. Your competitor’s six-month 1.0 has crap code and they’re going to have to rewrite it in two years but, guess what: they can rewrite it because you don’t have a job anymore."

[rimiform]

Shouldn't that worry you, rather than excite you? He's just saying "worse is faster", not "worse is better". Especially that last sentence is kind of terrifying: "they can rewrite it because you don’t have a job anymore." Basically, everyone who takes the time to write good code will be outcompeted by bad code written quickly, until eventually everything is bad.

[0x4d464d48]

I think 'annoy' is usually a more appropriate word than 'worry' (but not always). Markets and users are stochastic with no one really knowing what users are going to ask for, nor what competitors release and cause users to demand, well designed or not.

What a lot of these conversations boil down to is finding the sweet spot between over/under engineering which is subjective. Are we wasting time solving problems that dont matter or are we shipping with a 'just enough' type of mentality and risk exposing our users to buggy software?

No one likes to work with bad code but if its siloing itself into inconsequential CRUD apps or frivilous games/social media it's just annoying to experience/work with. Its when it creeps into systems or applications where consequences for failure are dire, think Lion Air crash in 2018, that Im worried.

[soco]

We're already giving all jobs to low cost centers and low cost employees and look where this is taking us: take home automation products as an example.

[capiki]

He's definitely saying "worse is faster" but he's also saying "worse is better," if what you're measuring is how good you're at shipping a product. And I think if you change "bad" to "good enough" (to be better than existing products) then you're right.

[notriddle]

“Eventually?” Everything already is bad.

[lmarcos]

Which is in some way sad.

I know we are not hired "to write code" but "to ship products", and that everything is done in "sprints" and we must be very agile in doing them because they're always non-stop, and quality comes second (unless, of course, you are really skilled and can ship high quality code in half the time it usually takes), and customers first and "we'll polish it in version 2" and...

I guess I feel "guilty" of writing good code just for the sake of writing good code (and taking time for doing so). At work code comes second, product comes first. I accept it and I try my best, but at the end of the day the code I write at my own pace at home for side projects, now that's the code I like to write.

[dpc_pw]

It's easy to do things slowly, by the book, taking all the time in the world, while the world is waiting. It's part of the skill and mastery to know which corners to cut and which things are essential and which can be fixed later, and judge the effort to result ratio accurately.

[twistedpair]

It's not so binary though. If "perfect" takes 3 years, and "mad-max" takes 6 months, how good and maintainable a product can you muster in 9-12 months?

There is non-linearity here where you beat the "6 month" competitor the following year, because their product is buggy as hell and unmaintainable, but you keep cranking out solid features on your maintainable codebase/infra.