Live data from Hacker News

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

exceptionnotfound.net

101–110 of 130 posts

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

#101
It might not be "perfect code", but I find it fascinating what certain institutions do to create bug-free and easily testable code, institutions which are involved in work where small errors can quite literally ruin billions of dollars of investment.

For example Coding Standards from NASA's Jet Propulsion Laboratory (JPL) for C[1] and Java[2]

This will also give you an idea of just how tedious it is to do so

I am not even sure if enforcing those strict standards leaves a Turing-complete language

[1] http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf

[2] http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_Java.pdf

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

#102
post #42
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…

Management doesn't invest in things they don't understand. They rarely understand tech (even if they are technical people, tech is misunderstood). If you care about the outcome of a craft, you'll get craftsmen, and they'll produce things and you'll pick the best ones. Imagine if a chef had to serve the first try at a new dish, if a photographer had to use his first shot, if a director had to use the first take, if a…

Instead of the 80-20 split at some tech cos, perhaps there should be a 70-20-10 split, of main project-side project-refactoring/cleanup. I would wager Google for example would be almost immeasurably better off with that approach.

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

#103

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…

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 ever seen in 20 years across all manner of marketplaces and every imaginable stage of development has had the immediate faux-gains made from ignoring spending 10%-20% more time now (to produce something at least coherent, commented, and composable) ultimately overwhelmed by the soon-to-be-immediate costs of having to live with the consequences of the dubious "shortcuts" taken.

I agree with you that it's extremely hard to achieve maintaining that kind of discipline when under the gun, but that's a people management and expectations problem, not an engineering effort problem. 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.

Lacking that discipline is neither a necessary condition nor a near or long-term benefit to a prototyping or product development cycle. It's purely a function of leadership, expectations management, and experience.

(I'm even giving the benefit of the doubt that what's being done "hasn't existed before", which is overwhelmingly not the case. More typically it's different people and different teams just painfully learning the same hard lessons in parallel, often because there's an assumption/delusion what's being done is a legitimate pioneering effort instead of the probable reality that it's really a minor variation on something else that already has well-established successful models available to learn from and mimic.)

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

#104
post #65

Unless it is formally verified, then it is really perfect. Not sure why we shouldn't strive towards that final state of evolution. Conceding the game at "good enough" is a cop out.

Formal verification depends on frozen requirements. These are quite rare in practice.

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

#105

It might not be "perfect code" , but I find it fascinating what certain institutions do to create bug-free and easily testable code , institutions which are involved in work where small errors can quite literally ruin billions of dollars of investment. For example Coding Standards from NASA's Jet Propulsion Laboratory (JPL) for C[1] and Java[2] This will also give you an idea of just how tedious it is to do so I am n…

That's a good point. Safety critical systems commonly require loops to have maximum iteration counters and also forbid recursion.

So what's left probably isn't Turing complete.

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

#106
We should more than ever strive for perfect code. Perfect as defined by all stakeholders in a software. There is really no point in striving for anything less. Sure you maybe forced to stop at one point (time and money beeing the limiting factors) but if you can, you should always continue making software better!

"Good enough" is not good enough as a target. It's uninspiring and unsatisfying.

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

#107

Tooling is getting better. Ever looked at what Amazon does with formal methods to "prove correctness" for some of their systems? Of course you can argue that "good enough" for them is "damn near perfect". http://cacm.acm.org/magazines/2015/4/184701-how-amazon-web-s...

got a link to a non-paywalled source?

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

#108

It might not be "perfect code" , but I find it fascinating what certain institutions do to create bug-free and easily testable code , institutions which are involved in work where small errors can quite literally ruin billions of dollars of investment. For example Coding Standards from NASA's Jet Propulsion Laboratory (JPL) for C[1] and Java[2] This will also give you an idea of just how tedious it is to do so I am n…

That's a good point. Safety critical systems commonly require loops to have maximum iteration counters and also forbid recursion. So what's left probably isn't Turing complete.

From [2] above:

> important general differences from the JPL institutional C coding standard for flight software references (JPL-C-STD) are: (1) the Java standard allows dynamic memory allocation (object creation) after initialization, (2) the Java standard allows recursion, and (3) does not require loop bounds to be statically verifiable. Apart from these differences most other differences are due to the different nature of the two languages.

That said, the standard in question is explicitly only intended for ground-based systems.

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

#109

Earlier quoted context omitted.

Perfection is subjective because flaws are subjective. Aesthetics are part of the code. If a piece of code is functionally perfect but ugly or inelegant by some measure, then it is imperfect by that measure.

right, flaws are subjective. I'll try that one on my QA team next time they file a bug report ;)

There is more than one class of flaw. Some are objective, ie. fail to meet spec. Some are subjective, typically where the spec doesn't cover.

If software functions correctly but is unnecessarily hard to use due to (eg.) bad layout, would you still call it perfect?

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

#110
post #45

Earlier quoted context omitted.

This isn't just in code these days. I'd call it the Ikea phenomenon. Things that look functional and act functional in a constrained set of circumstances, and are deemed as good enough. The cost is often proportionally low, too. (ever tried to move a fully loaded Ikea dresser?) But, as you've pointed out, the real work is in maintenance, durability, and quality, not veneers.

Arbitrarily relocatable furniture tends to be made of steel and weigh 300 lbs. I think the extended metaphor works for software as well.

That's a great metaphor...
Post reply on HN