Insanity is doing the same thing over and over again and expecting a different result.
Code Is Never “Perfect”, Code Is Only Ever “Good Enough”
31–40 of 130 posts
Re: Code Is Never “Perfect”, Code Is Only Ever “Good Enough”
#32Code quality can only ever be as good as your understanding of the problem domain. A more accurate statement would be "Problem domains are rarely perfectly understood."
Re: Code Is Never “Perfect”, Code Is Only Ever “Good Enough”
#33Perfect is subjective, but "correct" not so much. And when you get sufficiently skilled, you realize correctness can, for sufficiently complex software, only come together with the more subjective qualities, since it's hard to make "ugly" code correct.
"Piece of [bleep]! I know you [bleeping] work! WHY WON'T YOU [BLEEPING] WORK, MOTHER[BLEEPER]?!"
With that kind of attitude (trial-and-error?) you will never be able to consistently produce correct code, let alone perfect whatever that is. Though I think it's not typically the attitude that is the problem, but rather the underlying lack of skill/intelligence which makes people resort to such approaches.
Re: Code Is Never “Perfect”, Code Is Only Ever “Good Enough”
#34One of the depressing things about code is that it is astoundingly easy to build something that does amazing things in controlled circumstances but is otherwise practically garbage. Promotions, venture capital, and all other manner of rewards can result from said garbage. The “real work” is in figuring out how to move forward from something like that, and lots of stress comes from trying to do so without breaking any…
> The “real work” is in figuring out how to move forward from something like that, and lots of stress comes from trying to do so without breaking anything.
I'm a lot more impressed with the evolution of the human species than how doctors have been able to maintain those running systems.
You want to design a human from the ground up using proper infrastructure that doesn't have ailments or diseases go ahead. you'll be lucky if you end up with a fruit fly.
Re: Code Is Never “Perfect”, Code Is Only Ever “Good Enough”
#35Earlier quoted context omitted.
You are missing the point. "Good enough" depends entirely on the context. In some contexts, the bar for "good enough" will necessarily be quite high, while in other context it won't matter as much. There is no perfect code -- because no two humans could agree on such a definition. Sure, people may disagree on what is good enough. But hopefully that disagreement will be easier to resolve than one about what the perfec…
My only concern is that this line of thought can be used as an excuse to stop trying. As long as we agree that one should strive for perfection given the constraints at hand (money / time / problem difficulty / experience level etc) I dont have any objection about the idea. On a related note, I feel another analogous statement that I now see used dangerously is "Premature optimization is the root of all evil". Yes op…
I can appreciate that. I have some perfectionist tendencies myself. I think it is a tricky balance that must we must walk. I like your idea of "as perfect as our constraints allow".
Another important consideration is the level at which the quality exceeds the needs of current and future users of the software. Past this point (which might be impossible to determine or fully agree upon), one must acknowledge they continue to iterate and polish for purely personal reasons. This can be fine in certain situations, but it may be a detriment in professional endeavors.
And of course, like always, one must consider opportunity costs.
Re: Code Is Never “Perfect”, Code Is Only Ever “Good Enough”
#36I see things a bit differently. Some domains are well understood and it's relatively easy to write perfect code (e.g. mathematical functions, list manipulating functions, etc.), while in others it may be much harder (the file uploading example he mentions). To me a good aim of writing code is to move bits and pieces from the latter camp to the former, so that more and more of your codebase is well understood (and per…
Actually, I'd say writing perfect code in the mathematical domain is extremely hard - floating point types are a minefield and infinite-precision arithmetic is a minefield also if you consider the possibilities for running-times exploding. For example, code for the mean of a list of numbers is a hard problem when looked at in its full generality [1] - and that's using forgiving definition of "perfect" - alway correct and terminating, running at a reasonable speed.
Re: Code Is Never “Perfect”, Code Is Only Ever “Good Enough”
#37I see things a bit differently. Some domains are well understood and it's relatively easy to write perfect code (e.g. mathematical functions, list manipulating functions, etc.), while in others it may be much harder (the file uploading example he mentions). To me a good aim of writing code is to move bits and pieces from the latter camp to the former, so that more and more of your codebase is well understood (and per…
I get really twitchy when I read statements like yours. But I am completely unreasonable in my definition of perfect -- it is really beyond extreme. Perfect is an absolute, so by definition it is unobtainable. Perfect means you have gone beyond the notion of executes correctly every single time, but MUST also be aesthetically perfect. Perfect names, perfect formatting, perfect location etc. No one can meet my criteria for perfect and never will (I can't).
In that sense, there is no perfect code, nor will there ever be. There will only EVER be good enough.
Re: Code Is Never “Perfect”, Code Is Only Ever “Good Enough”
#38I had a manager that never used "finished" or "done". He always said "where it needs to be right now".
Re: Code Is Never “Perfect”, Code Is Only Ever “Good Enough”
#39One of the depressing things about code is that it is astoundingly easy to build something that does amazing things in controlled circumstances but is otherwise practically garbage. Promotions, venture capital, and all other manner of rewards can result from said garbage. The “real work” is in figuring out how to move forward from something like that, and lots of stress comes from trying to do so without breaking any…
There are definitely organizations where code that works but doesn’t appropriately account for those uncontrolled scenarios will earn you nothing more than a bad reputation. I’ve seen this happen, and I’ve seen their name slowly drift to the bottom of the list when it comes time for a raise or promotion.
I’m generally surprised at how little interest VCs have in this, though. I think a sizable percentage of their misses could’ve been avoided altogether if they had just audited their prototype, or whatever they’re claiming qualifies as their MVP.
People generally don't understand how many different scenarios software needs to account for, and how quickly those inputs can exponentiate into a very big and complex task. Creating the appearance of functional software takes a very small fraction of the time and expertise that it takes to actually make something production-ready, but I don’t think a lot of non-developers understand just how big that gap is.
Re: Code Is Never “Perfect”, Code Is Only Ever “Good Enough”
#40[deleted]