4 ms·

Ah, the minimalist software engineer. I usually encounter them in PRs claiming a change is "over-engineered" despite being literally 5 LOC. It's such a comforta

Ah, the minimalist software engineer. I usually encounter them in PRs claiming a change is "over-engineered" despite being literally 5 LOC. It's such a comfortable position to label everything you don't understand as complex and unnecessary. Bonus points of you throw in YAGNI and KISS acronyms! I have a problem with "Perfect is enemy of good". I get the whole thing with iteration and so on, it looks good on paper, but in my experience when it comes to "First do it, then do it right, then do it better" and modern software development methodologies, you are lucky if you even get to work on the second step. And the nastiest projects I've encountered in my career have been all "evolved".

deleted 4y ago
[deleted]
bayindirh 4y ago
"Perfect is enemy of good" is just another name for "make it run first, make it run fast next". It doesn't apply cleanly to everything, but if you have a deadline coming up, an acceptable solution which is gonna be polished in the very next iteration is a good compromise, IMHO. However, project management loves to mark things as complete, so getting it polished to usual standards is the hardest part.
deleted 4y ago
[deleted]
jrochkind1 4y ago
"perfect" is the enemy of "good", but so is "bad". Bad is definitely the enemy of good. So it winds up being arguments about whether something is "bad" or "good enough". I mean, that's kind of the whole damn trick, figuring out what is good enough. It's good to remember that "good enough" has upper as well as lower bands, it's true that perfectionism is not the way to go -- especially because you are usually over-confident in your ability to predict how something will actually turn out under real world use and requirements. But I also find people insisting "the perfect is the enemy of the good" while trying to do crap. Why bother trying to do better than crap, the perfect is the enemy of the good! Determining what is "good enough", over the sustainable long haul, is literally the whole trick to software design. At what point you are getting diminishing returns or even counter-productive complexity from trying to polish it further. If it was easy we wouldn't be having these conversations. Slogans still don't make it easy.
hbrn 4y ago
> you are lucky if you even get to work on the second step I've done over and over without any issues. In order to work on second step you need two things: 1. A plan (at least a vague one) of how will you execute the second step iteratively (i.e. without rewriting everything from scratch). 2. Actual business need for step 2. If you aren't able to execute step 2 without the Big Rewrite, then it's on you. Business doesn't want to take these risks. If your business doesn't need step 2, then what are we complaining about? I guess the only advice I have is stop treating step 2 as "step". It follows the same Pareto Principle: there's 20% of effort in step 2 which gives 80% of results.
- TurboHaskal 4y ago
  > If your business doesn't need step 2, then what are we complaining about? Hacky, non automated, low quality, not tested, hard to maintain, slow code. Remember, we are at step 1 of "First do it, then do it right, then do it better." Business rarely needs refactorings and performance improvements, until they do, and things turns really ugly when they do, because they've been focusing on shipping "good enough" crap instead of focusing on the actual "continuous improvement" they claim to do.
  - hbrn 4y ago
    > Hacky, non automated, low quality, not tested, hard to maintain, slow code Have you seen truck drivers complaining they are forced to drive old trucks and not brand new Ferraris? If low quality code gets shit done, why would company invest into high quality? Delivering goods in Ferraris might be hell of a fun for drivers, but it's a stupid decision for a trucking company. How confident are you that your high quality will pay off? When exactly will it pay off? How confident are you that your measurement of "high quality" is not biased? How confident are you that your teammate's perception of "high quality" is not just chasing new hype? > Business rarely needs refactorings and performance improvements, until they do, and things turns really ugly when they do Sure, and that's why it's your job to prepare for it. Not by creating "high quality" code in advance, but by creating low quality code that is malleable.
    - 4y ago

deleted 4y ago

[deleted]

bayindirh 4y ago

"Perfect is enemy of good" is just another name for "make it run first, make it run fast next". It doesn't apply cleanly to everything, but if you have a deadline coming up, an acceptable solution which is gonna be polished in the very next iteration is a good compromise, IMHO. However, project management loves to mark things as complete, so getting it polished to usual standards is the hardest part.

deleted 4y ago

[deleted]

jrochkind1 4y ago

"perfect" is the enemy of "good", but so is "bad". Bad is definitely the enemy of good. So it winds up being arguments about whether something is "bad" or "good enough". I mean, that's kind of the whole damn trick, figuring out what is good enough. It's good to remember that "good enough" has upper as well as lower bands, it's true that perfectionism is not the way to go -- especially because you are usually over-confident in your ability to predict how something will actually turn out under real world use and requirements. But I also find people insisting "the perfect is the enemy of the good" while trying to do crap. Why bother trying to do better than crap, the perfect is the enemy of the good! Determining what is "good enough", over the sustainable long haul, is literally the whole trick to software design. At what point you are getting diminishing returns or even counter-productive complexity from trying to polish it further. If it was easy we wouldn't be having these conversations. Slogans still don't make it easy.

hbrn 4y ago

> you are lucky if you even get to work on the second step I've done over and over without any issues. In order to work on second step you need two things: 1. A plan (at least a vague one) of how will you execute the second step iteratively (i.e. without rewriting everything from scratch). 2. Actual business need for step 2. If you aren't able to execute step 2 without the Big Rewrite, then it's on you. Business doesn't want to take these risks. If your business doesn't need step 2, then what are we complaining about? I guess the only advice I have is stop treating step 2 as "step". It follows the same Pareto Principle: there's 20% of effort in step 2 which gives 80% of results.

TurboHaskal 4y ago
> If your business doesn't need step 2, then what are we complaining about? Hacky, non automated, low quality, not tested, hard to maintain, slow code. Remember, we are at step 1 of "First do it, then do it right, then do it better." Business rarely needs refactorings and performance improvements, until they do, and things turns really ugly when they do, because they've been focusing on shipping "good enough" crap instead of focusing on the actual "continuous improvement" they claim to do.
- hbrn 4y ago
  > Hacky, non automated, low quality, not tested, hard to maintain, slow code Have you seen truck drivers complaining they are forced to drive old trucks and not brand new Ferraris? If low quality code gets shit done, why would company invest into high quality? Delivering goods in Ferraris might be hell of a fun for drivers, but it's a stupid decision for a trucking company. How confident are you that your high quality will pay off? When exactly will it pay off? How confident are you that your measurement of "high quality" is not biased? How confident are you that your teammate's perception of "high quality" is not just chasing new hype? > Business rarely needs refactorings and performance improvements, until they do, and things turns really ugly when they do Sure, and that's why it's your job to prepare for it. Not by creating "high quality" code in advance, but by creating low quality code that is malleable.
  - 4y ago