next time just post the prompt
Perfection is not over-engineering
81–90 of 132 posts
Re: Perfection is not over-engineering
#82Sure, but did it need to be written by AI? Does that solve for the right constraint?
Re: Perfection is not over-engineering
#83Earlier quoted context omitted.
The number of times I've heard that phrase used to justify shipping absolute crap utterly dwarfs the times it's been used to prevent over-engineering something that's already in a good state. In a thirty year career of software engineering, I haven't once come across one of these mythical perfectionists that everyone is constantly retelling cautionary tales of, who endlessly rewrites perfectly serviceable software an…
> I haven't once come across one of these mythical perfectionists that everyone is constantly retelling cautionary tales of, who endlessly rewrites perfectly serviceable software and never releases Oh, I have. A LOT! In my friend group theres at least 5 of these right now. They work day jobs (that they dislike), they try to build a side hustle but never get it off the ground because they endlessly rewrite perfectly s…
I'm just like that, but minus the expectation of release/money/success. To me, the building and programming itself is the reward, and I have no motivation or desire to release anything I work on--or any belief that it would/should make money for me. To me, the hours spent fine sanding down and polishing my code, always approaching but never achieving perfection, is its own reward.
Re: Perfection is not over-engineering
#84"We're not trying to build a perfect solution here" is not something said to assuage over-engineering or encourage sloppy work. It's said to head off a specific complaint from a specific kind engineer who will object that the proposed solution won't work because it doesn't cover some obscure edge case which rarely comes up in production. "We're not trying to build a perfect solution here" is saying "We acknowledge no…
My grandpa used to say "we're not building a piano" when doing things like building a quick shelf or something in the basement and be done after a quick measure and a few cuts. My other grandpa would spend an entire day measuring, sanding, pulling out a router etc. Both valid, but if you just need something to put some paint cans on, it doesn't require a day of work.
hahah I picked that up from a youtube woodworker when I was a CALENDAR YEAR into building my son's toy chest. A lot of measurements I had sweated over didn't matter; they are inside of the channels on shaker panels. A bunch of things I didn't sweat are apparent; not ever pencil mark got sanded off before I oiled it and I didn't notice.
Re: Perfection is not over-engineering
#85"We're not trying to build a perfect solution here" is not something said to assuage over-engineering or encourage sloppy work. It's said to head off a specific complaint from a specific kind engineer who will object that the proposed solution won't work because it doesn't cover some obscure edge case which rarely comes up in production. "We're not trying to build a perfect solution here" is saying "We acknowledge no…
> We acknowledge not everything will be covered, we're setting the requirements at the 90th percentile use case
I'm ok with this as long as dropped requirements are documented and nobody wakes you up at night when those edge cases show up in production. Also, when the next feature needs to build on top of those dropped edge cases, you are given enough resources to redo the previous solution.
Re: Perfection is not over-engineering
#86I'm all for pushing back against "let's not make perfect the enemy of good." I hear that all the time in reference to software that is usually quite bad, and often a little evil to boot--nothing good anywhere in sight except some poor schmuck trying to find a way to make their job something worth taking pride in. I'm not sure I agree that systems are products though. The product mindset is toxic. It means that you've…
> “let's not make perfect the enemy of good."
Nuanced, but I’ve heard “don’t let perfection be the enemy of completion”, which is real in the cases of not shipping because one is constantly polishing/perfecting, or, as I heard sitting beside phk[0] at BSDCan commenting on rejecting some environmental sensors into FreeBSD, something to the effect of “We need ‘good’, not ‘good enough’.”, which draws a line at accepting janky “solutions” that are architecturally weak, or otherwise look obviously problematic.
Re: Perfection is not over-engineering
#87I'm all for pushing back against "let's not make perfect the enemy of good." I hear that all the time in reference to software that is usually quite bad, and often a little evil to boot--nothing good anywhere in sight except some poor schmuck trying to find a way to make their job something worth taking pride in. I'm not sure I agree that systems are products though. The product mindset is toxic. It means that you've…
The number of times I've heard that phrase used to justify shipping absolute crap utterly dwarfs the times it's been used to prevent over-engineering something that's already in a good state. In a thirty year career of software engineering, I haven't once come across one of these mythical perfectionists that everyone is constantly retelling cautionary tales of, who endlessly rewrites perfectly serviceable software an…
I was one of those initiators of a rewrite. And I was facing a real problem: the codebase was in C, all C developers except me left, I was going to leave too, and both our HR department and an external consulting firm failed to find a competent C developer to replace me.
So I said: screw performance, we are rewriting this thing into Go, as that's what our existing developers were willing to work with - with the intention of leaving when this would be done.
And the day I finally submitted my resignation letter, a competent C developer was found, and later I heard that the Go rewrite was scrapped.
Re: Perfection is not over-engineering
#88I'm all for pushing back against "let's not make perfect the enemy of good." I hear that all the time in reference to software that is usually quite bad, and often a little evil to boot--nothing good anywhere in sight except some poor schmuck trying to find a way to make their job something worth taking pride in. I'm not sure I agree that systems are products though. The product mindset is toxic. It means that you've…
Yes, agreed, that quote is not as relevant to software development. Some would make the case that software isn't good unless it's perfect. Engineers will use the word 'correct' (e.g. correctness); and by that, they mean; is it perfect... And it's not wrong to demand it because the smallest gap can be a critical security vulnerability.
Re: Perfection is not over-engineering
#89Perfection is the enemy because the very notion of it assumes that something cannot be any better. Everything can always be better. That's the problem. Whatever solution you make, will eventually be "not good enough". Follow that path long enough and you will never be done with anything. So not only do you need to realize perfection is impossible, but you also need to accept "the bad" and live with it, or become Sisyphus.
Re: Perfection is not over-engineering
#90Earlier quoted context omitted.
I've been that engineer and with good reason. That obscure edge case which rarely comes up in production is very disruptive when it does come up. The product person waving it off is also not the one that will get paged at 2am to address the issue when it occurs. Accepting that 90th percentile use case is infuriating because it is tacit consent for an unfinished solution with the rest being made up later with addition…
Don’t forget months or years later when shit hits the fan, developers will be blamed for being lazy and not the product person. No one will remember Joe said something on one or two meetings we build for 90th percentile - code in git repository will point to a developer who wrote and GitHub will point to the one that approved merge request. In online discussions people always blame „lazy developers „ like there would…
This is one of the reason I like a ticket tracker. I make my commit as descriptive as possible and I tag them with the ticket number. Also I add comments when Product says to cut corners. It's nice to spread responsibility around when things take a bad turn.