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

Code Is Never “Perfect”, Code Is Only Ever “Good Enough”

exceptionnotfound.net

Post reply on HN
Print view View original

91–100 of 130 posts

Re: Code Is Never “Perfect”, Code Is Only Ever “Good Enough”

#91

Post by marcosdumay »

steego wrote: post #44

It's important to know what kind of code you're working on before you start setting low standards. Some code is perfect, but it's only perfect because it was define with extreme mathematical precision (Ex: Haskell Prelude code). The value of this type of code is in direct proportioned to how often it's reused. Often the specs are based on timeless and well defined ideas, and the implementation crystallizes. On the ot…

I stopped looking for perfect code after I saw the fail man page, and saw that the one on my computer was at version 4.something.

Yes, the Haskell's Prelude is perfect when matched with an (artificial) specification that requires exactly it. Yet, on practice I don't think I ever saw any Haskeller that does not want to add or remove something from it. Partial functions are almost unanimously disliked, ditto for String functions; not to say about the universal complaints in how it is badly generalized.

Re: Code Is Never “Perfect”, Code Is Only Ever “Good Enough”

#92

Post by dahart »

mikekchar wrote: post #86
dahart wrote: post #85

I still haven't learned this lesson well enough. Code I think is near perfect always turns imperfect over time. The main corollary for me is that I can spend every waking second of my life making my code better, and I'll never be happy. I want to better figure out how to enjoy 'good enough'.

Instead, I might suggest that you enjoy making your code better and to be happy with the process rather than the result. Then every crappy piece of code is an opportunity rather than a curse. Improving code beyond the point where it gives material benefit is not really a problem except for the fact that it deprives you of the opportunity to work on crappier code. Especially when working with new code, I find it usefu…

I was getting closer to that for many years -- enjoying the process -- until I decided to try and start a software business. All of a sudden, there's a huge downside to improving code without having a clear material benefit.

I'm with you on losing the fear of writing crappy code being freeing. At some point I realized that everyone's code including mine is crappy code, and there's no way around writing crappy code or introducing bugs. Realizing that did make me a better coder and a better manager. It let me be a bit more humble as well as empathetic to others, and led me to think more about the importance of testing.

Re: Code Is Never “Perfect”, Code Is Only Ever “Good Enough”

#93

Post by im_down_w_otp »

Retric wrote: post #87
cocktailpeanuts wrote: post #75

Earlier quoted context omitted.

What you say is indeed important, but I wouldn't say the work before that is not "real work". It's just different types of work. Ask any successful startup founder what their initial codebase was like and they would say--if they're honest--it was shitty. There's a reason for this. The "real work" you mention comes into play only after the product has reached product market fit and needs scaling. Before that phase, it…

Early work is closer to a lottery than anything else. If you only look at winners you will end up with a distorted view, but right product, right time, right market is more about luck than skill. MVP is all about validation because there is no way to judge good vs great before you build it. So, the only way to improve odds is to just roll more dice.

You can still write great code (meaning: clean non-leaky abstractions, proper separation of concerns, functional testing, clearly organized, and unintuitive bits documented) without having market validation, and I'd suggest that doing so will actually make it a lot easier for you to shift the pieces of the project, remove them, rewrite them, extend them, etc. as you start to hone in on the marketplace fit, and doubly so as you need to start growing your development team and need to on-board them effectively so everyone can be productive without just rapidly accruing compound interest on the technical debt that's already there.

It doesn't take that much longer to write great code when it's just part of the first-principles of your engineering process. You just do it as you go, but best-practices need to be scaffolded and modelled for everyone beforehand to give them a solid starting point for what "minimally viable" actually looks like. A single well-placed sentence that describes something necessary, but non-idiomatic or non-obvious, that takes 10sec to write can save you hours or days of tracing and debugging at that crucial moment right before you're onboarding a pilot customer or pitching investors.

Very often the bar of "minimally" is set way, way too low and the trope of that just being "startup life" is usually just laying problems at the feet of engineering that don't belong there by justifying, sometimes horrifying, technical debt which are really process and management failures, and later eventually scapegoating engineering for it.

Re: Code Is Never “Perfect”, Code Is Only Ever “Good Enough”

#94

Post by hypertexthero »

I [attended][1] a great lecture by [Alex Martelli][2] back in EuroPython 2013 titled "'Good Enough' is Good Enough!"

From the [summary][3]:

> Our culture’s default assumption is that everybody should always be striving for perfection – settling for anything less is seen as a regrettable compromise. This is wrong in most software development situations: focus instead on keeping the software simple, just “good enough”, launch it early, and iteratively improve, enhance, and re-factor it. This is how software success is achieved!

[1]: http://simongriffee.com/notebook/europython-2013-notes#goode... "My notes. Biggest takeaway was to use 'perfect' as a verb rather than adjective."

[2]: http://www.aleax.it/ "Alex's homepage."

[3]: https://ep2013.europython.eu/conference/talks/good-enough-is... "The lecture video is also on the page."

Re: Code Is Never “Perfect”, Code Is Only Ever “Good Enough”

#95

Post by logicallee »

smt88 wrote: post #69
logicallee wrote: post #34

Earlier quoted context omitted.

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

The human body is the result of 1,000,000,000,000,000,000,000+ organisms dying before or after reproducing. That's evolution. It has absolutely nothing to do with the "maintenance" that doctors perform on the human body, especially when doctors are loathed to lose even a single organism. I'm not even sure why I responded to your comment, since it was so random and unrelated to the rest of the thread.

It means you didn't understand my comment.

>The human body is the result of 1,000,000,000,000,000,000,000+ organisms dying before or after reproducing.

I guess I have to spell it out. "Bad, unmaintainable code" is the result of 1,000,000,000,000,000,000,000+ random requests being shoehorned in without proper design of the whole thing, but just on the basis of whether it still works or meets some last-minute requirement. I hope this makes my analogy clearer. (I realize the number is an exaggeration, I am referring to the process involved in "evolving" code, rather than "properly designing" it.)

Re: Code Is Never “Perfect”, Code Is Only Ever “Good Enough”

#96

Post by cocktailpeanuts »

im_down_w_otp wrote: post #93
Retric wrote: post #87

Earlier quoted context omitted.

Early work is closer to a lottery than anything else. If you only look at winners you will end up with a distorted view, but right product, right time, right market is more about luck than skill. MVP is all about validation because there is no way to judge good vs great before you build it. So, the only way to improve odds is to just roll more dice.

You can still write great code (meaning: clean non-leaky abstractions, proper separation of concerns, functional testing, clearly organized, and unintuitive bits documented) without having market validation, and I'd suggest that doing so will actually make it a lot easier for you to shift the pieces of the project, remove them, rewrite them, extend them, etc. as you start to hone in on the marketplace fit, and doubly…

I agree with you in theory, but from experience it is extremely hard to achieve when you're actually in that position.

Unlike what you say, it does take much longer to write great code when you're trying new things every day. Every time you try something new, by definition you're building something that you hadn't planned when you first started. Which means if you really wanted to be perfect you would end up refactoring every day. This is not a small effort in total.

You could say you should have prepared for that scenario from the beginning, but I don't think it's a good idea to believe that you can predict the future especially when you're building something that hasn't existed before.

Re: Code Is Never “Perfect”, Code Is Only Ever “Good Enough”

#97

Post by ddaygold »

SilasX wrote: post #26
patrickmn wrote: post #3

Earlier quoted context omitted.

I don't know if we will ever have tools that are that safe and as easy to use as the alternatives.

It depends. People were reluctant to give up a lot of bad coding practices (goto, variable scoping, writing in efficient assembly rather than a high-level language, mutable global state) until the better way had better tools or was taught better. Edit: Maybe one day people will look back and say, "you shipped code without formal correctness proofs? Were you all high?"

There is code that pushes the boundaries of the human mind, complex systems that cannot have any additional complexity if they are to succeed.

And there's other code that pushes against physical or economic limits: processor speed, memory available, network latency. In those systems, writing in an inefficient, high level language is just as wrong as writing the first type of code in a low level one.

Fast, complex, difficult to fully verify code is not bad coding practice any more than a rocket is a worse vehicle than a Volvo because it explodes more. Volvos can't go to space.

Re: Code Is Never “Perfect”, Code Is Only Ever “Good Enough”

#99

Post by rrecuero »

cocktailpeanuts wrote: post #75
makecheck wrote: post #17

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

What you say is indeed important, but I wouldn't say the work before that is not "real work". It's just different types of work. Ask any successful startup founder what their initial codebase was like and they would say--if they're honest--it was shitty. There's a reason for this. The "real work" you mention comes into play only after the product has reached product market fit and needs scaling. Before that phase, it…

Couldn't agree with it more. "Walking on water and developing software from a specification are easy if both are frozen".

Startups are the opposite of having clear requirements. There is a lot of uncertainty. In my opinion, it is usually orders of magnitude harder to figure out what to dot hat gets suers than building something "perfect" that nobody cares about

Post reply on HN