3 ms·

> First do it Sounds like your codebase will be full of shitty half-backed half-non-needed "features" with a lot bugs, legacy, and misdirection. > then do it

> First do it Sounds like your codebase will be full of shitty half-backed half-non-needed "features" with a lot bugs, legacy, and misdirection. > then do it right Sounds like your codebase will have a lot of hyped, now-dead, trends-of-the-moment frameworks while your team keeps arguing what's "right". > then do it better Sounds like your codebase will have a lot of rewrite in the new hyped, not-yet-dead, trends-of-the-moment frameworks while actual business logic will be ignored. In my experience, this is the worst advice if we are talking about software engineering. I would advise the opposite: "Is this needed? really needed? nerd out on why it's needed."

cj 3y ago
Considering the failure rate of startups (assuming we’re applying the advice in that context), you shouldn’t be worried about rewriting your codebase or using a hyped framework that will be outdated in 5 years because chances are (statistically) your startup won’t exist in 5 years. The opposite advice has merit, but you can’t take it to the extreme. Better to build a MVP in 1 month than to spend 6 months doing user research and then another 6 months building a MVP with perfectly performant and optimized code
codekaze 3y ago
Seriously, throwing shade at the 'launch fast, iterate fast' mantra is like saying the Wright brothers should have aimed for a Boeing 747 on their first go. The beauty of the MVP approach isn't in launching with a pile of 'shitty half-backed features.' It's about getting it in the hands of real users as quickly as possible so that you can start to iterate.
stillbourne 3y ago
>> First do it POC code doesn't belong as a permanent codebase. >> then do it right > Sounds like your codebase will have a lot of hyped, now-dead, trends-of-the-moment frameworks while your team keeps arguing what's "right". Doing it right should include a framework. I'd rather use a framework that is dead in a month than write 10s of 1000s lines of boilerplate to make my own. ASP.NET and Spring come to mind as modern reliable frameworks. Even angular is reliable even if not popular. >> then do it better > Sounds like your codebase will have a lot of rewrite in the new hyped, now-yet-dead, trends-of-the-moment frameworks while actual business logic will be ignored. Code should be considered disposable when it has outlived its usefulness. Even if that requires a rewrite. I've maintained classic asp websites and I have rewritten them in modern frameworks. Projects are not immutable. They are only as useful as they are until they are not. Then they die or get rewritten.
pixl97 3y ago
>I would advise the opposite: "Is this needed? really needed? nerd out on why it's needed." In almost every company I've seen "Is this needed" is always followed up by some c-level saying "Of course it fucking is, we've sold the product for $X million to $Y company and now we need that feature working" HN has a fair number of commenters that live in a dream world where they get to implement the features they choose, but for the vast majority of programmers it's going to be the features sales chose.

cj 3y ago

Considering the failure rate of startups (assuming we’re applying the advice in that context), you shouldn’t be worried about rewriting your codebase or using a hyped framework that will be outdated in 5 years because chances are (statistically) your startup won’t exist in 5 years. The opposite advice has merit, but you can’t take it to the extreme. Better to build a MVP in 1 month than to spend 6 months doing user research and then another 6 months building a MVP with perfectly performant and optimized code

codekaze 3y ago

Seriously, throwing shade at the 'launch fast, iterate fast' mantra is like saying the Wright brothers should have aimed for a Boeing 747 on their first go. The beauty of the MVP approach isn't in launching with a pile of 'shitty half-backed features.' It's about getting it in the hands of real users as quickly as possible so that you can start to iterate.

stillbourne 3y ago

>> First do it POC code doesn't belong as a permanent codebase. >> then do it right > Sounds like your codebase will have a lot of hyped, now-dead, trends-of-the-moment frameworks while your team keeps arguing what's "right". Doing it right should include a framework. I'd rather use a framework that is dead in a month than write 10s of 1000s lines of boilerplate to make my own. ASP.NET and Spring come to mind as modern reliable frameworks. Even angular is reliable even if not popular. >> then do it better > Sounds like your codebase will have a lot of rewrite in the new hyped, now-yet-dead, trends-of-the-moment frameworks while actual business logic will be ignored. Code should be considered disposable when it has outlived its usefulness. Even if that requires a rewrite. I've maintained classic asp websites and I have rewritten them in modern frameworks. Projects are not immutable. They are only as useful as they are until they are not. Then they die or get rewritten.

pixl97 3y ago

>I would advise the opposite: "Is this needed? really needed? nerd out on why it's needed." In almost every company I've seen "Is this needed" is always followed up by some c-level saying "Of course it fucking is, we've sold the product for $X million to $Y company and now we need that feature working" HN has a fair number of commenters that live in a dream world where they get to implement the features they choose, but for the vast majority of programmers it's going to be the features sales chose.