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

111–120 of 130 posts

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

#111

Post by sangnoir »

im_down_w_otp wrote: post #103
cocktailpeanuts wrote: post #96

Earlier quoted context omitted.

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

In my experience, when you're in the "invention phase" is when it's most critical and beneficial to have and demand more discipline around your output artifacts. Precisely because keeping context and content around your fast iterative decision-making and implementation phases is critical to avoid wasting time on duplicated effort or needlessly repeating mistakes over and over again. Literally every situation I've eve…

> I'm 100% certain that in any given window of time, no matter how crunchy that crunchtime is, that if my team spends 10-15 out of every 100 man-hours producing a higher-quality "minimally acceptable" artifact that they'll both materially accomplish more in that first 100 hours than if they'd spent all of it hacking together a barely working dumpster-fire in the same window of time, and that it will pay glaringly obvious dividends for their productivity in the next 100 hours after, and the next after that, and so on

The problems is at the very beginning, all (or most) of that code will be thrown away because you really don't know what works. How many cycles of wasted extra 20% effort would it take for you to change your mind?

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

#113

Post by coldnebo »

I think that might be paraphrasing implications of Gödel's Incompleteness Theorem.

Non-trivial codes can either be consistent or complete, but not both (within a system of abstraction).

This explains Joel's "Leaky Abstractions" essay as well as the conjecture that code cannot be perfect.

However, "good enough" thinking is often just sloppy thinking. Even if mathematics has boundaries, it doesn't mean you just shrug and say "a nod is as good as a wink".

Craftsmanship and quality are perceived in terms of utility over time. "Good enough" often doesn't meet that bar.

Engineers overbuild to support capacity and plan for the worst. "Good enough" tends to under-build at or below capacity and hope for the best.

"Good enough" is a just reaction to over-engineering (the adding of unnecessary fixtures and 'perfection'), so the warning has value and there are some engineers who use it in this way.

But others often mistake over-building for over-engineering and cripple their organizations and products by seeking "good enough".

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

#114

Post by Retric »

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…

Writing bad code is often the first step in writing novel good code. It's the 'does this library do what it says it does' kind of exploration. Can I do this in HTML 5?

First principles works fine on CRUD apps, less so new concepts. If you going to toss 90% of your code as useless then an extra 20% is simply wasted time. I am going to try the same thing in 5 library's to see which one I like directly means tossing 80% of that effort away.

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

#115

Post by beat »

flukus wrote: post #79
beat wrote: post #12

Earlier quoted context omitted.

Enterprise apps are no different. Lean startup is doing better in the enterprise than it is in the "startup" world. Early on, every app is laden with technical debt. They barely work. When "barely works" becomes "doesn't work", we fix them just enough so they barely work again, and start piling on more features and functionality. We may build some scaffolding and do some refactoring to prevent dropping into doesn't-w…

"Early on, every app is laden with technical debt. They barely work. When "barely works" becomes "doesn't work", we fix them just enough so they barely work again, and start piling on more features and functionality." This is the biggest issue, software is seen as something that is built, not something that has to be maintained, improved and extended. It's amazing how companies can pour tens of millions into the buil…

They don't lose the investment, though. They put it in back-burner mode where very little effort is expended, re-org the team to work on something else, and the software continues to generate revenue. It's a pattern I've seen a lot.

Another one of those real-world insights I've had is a variant of Conway's Law... the software built by a team reflects that team's communication structures, but if you dissolve the team and hand maintenance to someone else, they'll never make sense of the original code, because it doesn't match the communication structure of the new team.

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

#116

Post by im_down_w_otp »

Retric wrote: post #114
im_down_w_otp wrote: post #93

Earlier quoted context omitted.

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…

Writing bad code is often the first step in writing novel good code. It's the 'does this library do what it says it does' kind of exploration. Can I do this in HTML 5? First principles works fine on CRUD apps, less so new concepts. If you going to toss 90% of your code as useless then an extra 20% is simply wasted time. I am going to try the same thing in 5 library's to see which one I like directly means tossing 80%…

I completely disagree. It's much less useful for "CRUD apps" because "CRUD apps" are an obvious and known commodity. New and novel concepts are much less broadly intuitive, and are precisely the kinds of things that demand extra rigor even if you're going to end up throwing it all away. None of it is wasted effort when you're considering, and admitting, that a big chunk of the work is exploration.

Keeping documented feature branches of all those versions you tried before landing on one is an absolutely critical result of any exploration process, as well as some aggregation of information and context in a central place that points to and describes those various versions and your final outcome. This helps you keep from repeating mistakes, it provides context to you and others in the future for why things are the way they are, and it provides an archive of workable variations that you can quickly migrate to in the event your "final answer" turns out to be wrong.

I haven't written a "CRUD app" since 2008, and since 2010 nearly all my work and the work of my teams has been in greenfield development (in some cases literally inventing new never before seen things). I see it time and time again. We move much, much slower as individuals and as a group when we take shortcuts under the auspices of time-pressure and don't take the time to be thorough even in prototyping.

So we spend the same 100 hours hacking away to create a dumpster filled with spaghetti as fast as possible or we spend 100 hours designing, building, implementing with intention, and every. single. time.... the latter process actually gets us further toward prototype, product, and/or market validation goals. The former process ensures that we have 0% of anything that is useful no matter what the results of the exercise are. The latter process ensures that we can legitimately iterate on what we've done based on the results of the exercise.

Iterating on a trash heap is extremely expensive, not a way to run faster.

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

#117

Post by SilasX »

ddaygold wrote: post #97
SilasX wrote: post #26

Earlier quoted context omitted.

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

But one day our skill in "controlling explosions" (bad logic) may be as good as our skill at doing so in a Volvo, where we can get the power, with the efficiency and predictability.

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

#118

Post by im_down_w_otp »

sangnoir wrote: post #111
im_down_w_otp wrote: post #103

Earlier quoted context omitted.

In my experience, when you're in the "invention phase" is when it's most critical and beneficial to have and demand more discipline around your output artifacts. Precisely because keeping context and content around your fast iterative decision-making and implementation phases is critical to avoid wasting time on duplicated effort or needlessly repeating mistakes over and over again. Literally every situation I've eve…

> I'm 100% certain that in any given window of time, no matter how crunchy that crunchtime is, that if my team spends 10-15 out of every 100 man-hours producing a higher-quality "minimally acceptable" artifact that they'll both materially accomplish more in that first 100 hours than if they'd spent all of it hacking together a barely working dumpster-fire in the same window of time, and that it will pay glaringly obv…

You missed the point. In that same 100 hours, spending 15-20 hours applying best-practices has universally resulted in actually getting more out of that 100 block. The 100 hours spent on the spaghetti mess has always produced less, provided fewer insights, and often exactly nothing that can be soundly iterated on.

This is because the friction and pain of technical debt doesn't wait until the end of the 100 hours to create problems. It's biting you every second of every minute of every hour and dragging down your productivity and velocity as you're just plowing forward soaking the noodles.

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

#119

Post by geebee »

This reminds me or a reaction I had to a very old internet war about PHP and Rails

https://sivers.org/rails2php

"...The entire music distribution world had changed, and we were still working on the same goddamn rewrite. I said fuckit, and we abandoned the Rails rewrite."

It made a bunch of people mad, because (I think) they were reading "Rails couldn't X, and Rails couldn't Y, and Rails couldn't Z, but PHP could totally Y Z and Y, so I used PHP and it was a big success".

But having been in this situation, I think what he was saying was "I couldn't X, and I couldn't Y, and I couldn't Z, so I said fuckit and did it the way I know how..."

It has nothing to do with rails or PHP, or node, django, react. Programmers who have never finally said "fuckit" and abandoned "the true and right way" are programmers who haven't released.

Not saying you should stick with ancient technology, but "good enough" is an inevitable ingredient in any software that ends up being useful to someone.

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

#120

Post by Retric »

im_down_w_otp wrote: post #116
Retric wrote: post #114

Earlier quoted context omitted.

Writing bad code is often the first step in writing novel good code. It's the 'does this library do what it says it does' kind of exploration. Can I do this in HTML 5? First principles works fine on CRUD apps, less so new concepts. If you going to toss 90% of your code as useless then an extra 20% is simply wasted time. I am going to try the same thing in 5 library's to see which one I like directly means tossing 80%…

I completely disagree. It's much less useful for "CRUD apps" because "CRUD apps" are an obvious and known commodity. New and novel concepts are much less broadly intuitive, and are precisely the kinds of things that demand extra rigor even if you're going to end up throwing it all away. None of it is wasted effort when you're considering, and admitting, that a big chunk of the work is exploration. Keeping documented…

If your working from an existing code base then it's not green field development. It literally means development that lacks constraints imposed by prior work. For example sticking with an exiting language, OS, compiler, etc. is a constraint.

So, clearly we are talking about something different.

Post reply on HN