Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Perfection is not over-engineering

var0.xyz

Post reply on HN
Print view View original

101–110 of 132 posts

Re: Perfection is not over-engineering

#101

Post by lazyasciiart »

stouset wrote: post #98
malux85 wrote: post #74

Earlier quoted context omitted.

> 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 couldn’t care less about solo developers who never release their hobby projects. The cautionary tales are always about potential coworkers , and as far as I can tell that stereotype simple doesn’t exist in the business world.

I have not just worked with but had code rejected by these people. “Don’t fix that bug, we are going to write an entire new structure that will make it irrelevant”, “don’t upgrade that library, we are going to rewrite our code to not use it”, “don’t improve exception handling, fix all the bugs that throw bad exceptions”. Not at all surprisingly, all of those planned upgrades took at least two years after my attempted improvement was rejected (the library I didn’t upgrade stuck around for six years).

Re: Perfection is not over-engineering

#102

Post by lazyasciiart »

__MatrixMan__ wrote: post #5

I'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…

That’s a nice thought, but who are the users who plan to write their own air traffic control tool?

Re: Perfection is not over-engineering

#103

Post by imtringued »

stouset wrote: post #64
__MatrixMan__ wrote: post #5

I'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'm that perfectionist and it is constantly preventing me from shipping. Basically everything I'm working on requires me to cut losses at some point because it would take twice or three times as long if done perfectly and there is no guarantee that it is actually perfect in the end.

I don't really feel it collapsing under the weight of unmaintainable spaghetti tech stacks, I'm mostly thinking that writing the missing features of the tech stack would require months of work and hard thinking that in the end might simply get rejected and now I would be stuck maintaining it myself so nothing has changed other than that there are even more things to maintain.

All of this for the sake of clean architecture that seemingly has no impact on users in the end... Like the users complain about completely different things.

Re: Perfection is not over-engineering

#104

Post by malux85 »

ryandrake wrote: post #83
malux85 wrote: post #74

Earlier quoted context omitted.

> 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.

I would say thats a different thing entirely, an amateur in the original sense of the word

Latin amator, French amateur, means lover.

In this sense, it means somebody who is doing something because he/she loves it, not as his/her profession. It is not a large semantic shift to infer that he/she is not as skilled.

Re: Perfection is not over-engineering

#105

Post by nickelpro »

okwhateverdude wrote: post #46
nickelpro wrote: post #8

"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…

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…

> it is tacit consent for an unfinished solution

No. It is cutting unused features to make a manageable product.

* "That won't work on GCC 5.5." We don't support GCC 5.5, or any compiler which wasn't shipped this decade.

* "What about FreeBSD?" What about it? We only have Linux servers

* "This only works on systemd." Good, we're a systemd shop.

Re: Perfection is not over-engineering

#107

Post by laszlojamf »

The caveat here is, as TFA states, is that you need to have "every constraint on the table". And that is almost never the case. Unless you create something in a mature domain, where everything has already been explored, you _won't know_ what the constraints are.

You can spend three months in whiteboard sessions planning out the perfect solution, and then your plan falls apart the second you start implementing, because the real world imposes constraints on you that were practically impossible to know a priori. Not theoretically impossible, mind you. If you'd been smart enough and spent enough time thinking about it, you would have thought of them. But you aren't smart enough, and you don't have the time. Those are some other constraints that the universe puts on you.

Re: Perfection is not over-engineering

#108

Post by BiteCode_dev »

laszlojamf wrote: post #107

The caveat here is, as TFA states, is that you need to have "every constraint on the table". And that is almost never the case. Unless you create something in a mature domain, where everything has already been explored, you _won't know_ what the constraints are. You can spend three months in whiteboard sessions planning out the perfect solution, and then your plan falls apart the second you start implementing, becaus…

We spent 20 years talking about agile precisely because of this, and people took it, turned it into a checklist based processed, forgot about the short feedback loop it's precisely supposed to bring to the table to figure our your unknown unknown quickly, and declared it useless.

And now we are back to square one, where we argue again "but just make good specs".

The world is a silly place.

Re: Perfection is not over-engineering

#109

Post by KaiserPro »

__MatrixMan__ wrote: post #5

I'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…

Its about pragmatism. The problem is that a lot of software engineering tends to be not about building a product to service the buisness need.

Lets be honest, a lot of the time engineering decisions are made because "it would be cool to use x" rather than "this is the fastest path to achieving business goal z"

"over engineering" in a lot of cases is just either engineering gate keeping "oh you don't know how to do x properly, its soooooo much more 'performant' than y" or design by CV "lets use kafka, k8s, mobile app, AI, RAG" etc etc etc.

in 99% of cases, the architecture really doesn't matter that much, you product is never going to need what ever fancy system you put in. Mainly because people over estimate scale.

The thing that matters is that the customer is able to use it, and know how to use it. Everything else is almost irrelevant.

Re: Perfection is not over-engineering

#110

Post by Talpur1 »

Agree with over all post but one thing that always haunts me while engineering is perfection means what? a perfection that i want to engineer or a perfection that is based on response from users/ market, would love to have your thoughts on this angle
Post reply on HN