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

61–70 of 130 posts

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

#61

Post by kazinator »

chjohasbrouck wrote: post #39
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…

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

Software VC's don't have to care about code being crap that only demonstrates well in a particular set of circumstances for exactly the same reason that mining VC's don't have to care that the same fraction of gold is found in every cubic meter of the company's mining site as in the handful of lucky drill samples.

Those VC's can pump and dump: promote the stock stock, then dump it before it dives.

The people that have to care are the company officers who want to grow a successful business. If those people are cynical, then the venture is probably doomed.

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

#62

Post by lotyrin »

beat wrote: post #53
lotyrin wrote: post #42

Earlier quoted context omitted.

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…

If my house is on fire, I don't want the fire department to wait for the better firetruck for the job to show up. Time to market and allocation of resources are serious issues for management. They may not understand the tech, but I've found engineers rarely understand the business context, either. "Good enough" is good enough . And we've seen process get more and more focused on this since the late '90s... Agile, Lea…

Right, there's a whole spectrum between "a prototype worked once on Bob's laptop, how do we get that live" and "We invented 12 new declarative DSLs that encompass our problem domain, and formally proved their implementations correct."

Engineering isn't the latter end of that, it's precisely just the process of figuring out the trade-offs, the diligence of figuring out where on that spectrum (highly-dimensional continuum really) of process your project should be to get the greatest chances of success. Of course it includes time to market and concepts of "good enough". But it's math and planning and risk accounting and not the cargo culting, handwaving, business platitudes, salesmanship and politics of authority that get utilized in the majority of cases I've seen for making those decisions. These result in monuments to compromise -- the output of arguments between "captain cowboy" and "doctor diligent" (neither of which correctly account for real-world incidence of risk or what that costs the organization which employs them), arguments of engineering without any engineering being done.

Engineering isn't disconnected navel-gazing perfectionism, it's how you prevent it. Engineering is both why we don't live in Kowloon Walled cities, and why most places have water and plumbing and transportation despite a wide variety of obstacles and economic realities that would preclude "ideal" solutions.

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

#63

Post by bordercases »

patrickmn wrote: post #3
unimpressive wrote: post #2

I wonder if this attitude will change once things like coq become more accessible.

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

It's your job as a worker not to cut corners. It's their job as a manager to fire incompetence. Needless to say I think everyone is failing to do their job.

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

#64

Post by jfaucett »

Others wrote: post #58
jfaucett wrote: post #55

I think this is rambling about things that are largely unimportant (spaces or tabs). At least that's what his "Perfect Code" definition seems to be to me. The important part is the flipside, not the presentation: Given a problem domain and a context there is an optimal or "best" solution or there is not, and we can get at the answer for most cases. So code can be perfect if we understand perfect to mean optimal. If w…

I didn't read the whole paper you linked, but doesn't this sentence in the abstract contradict your last sentence? >Results indicate that camel casing leads to higher accuracy among all subjects regardless of training, and those trained in camel casing are able to recognize identifiers in the camel case style faster than identifiers in the underscore style.

yes it appears that way without reading the paper. Basically the main factor to me is speed which has a huge differential for untrained subjects "The model finds that identifiers written in the camel case style took 0.42 seconds more time." Doing the math you see how much wasted time that is. So I should have been more specific in the parameters. Your quote is perfectly valid as well.

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

#66

Post by jungrothmorton »

cwbrandsma wrote: post #37
rrradical wrote: post #14

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

You’ve created a concept and attached the word “perfect" to it. Your concept is different than the shared definition. This leads to disagreements, misunderstandings, and (as you said) twitching.

The purpose of words is to share information. If you have write a paragraph describing your definition when you use a word, use a different one.

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

#67

Post by cwbrandsma »

jungrothmorton wrote: post #66
cwbrandsma wrote: post #37

Earlier quoted context omitted.

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

You’ve created a concept and attached the word “perfect" to it. Your concept is different than the shared definition. This leads to disagreements, misunderstandings, and (as you said) twitching. The purpose of words is to share information. If you have write a paragraph describing your definition when you use a word, use a different one.

Not really. When I look up the definition, it is 'completely free of faults or defect'. I don't think I've strayed past that meaning.

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

#68

Post by cmillard »

It's scary sometimes that previous consultants (I'm a consulting developer) may have gotten an application "working", but have incurred so much technical debt it is nearly impossible to make changes. They've escaped and taken the biggest chunk of money leaving something built on a foundation of toothpicks. Thus the project becomes a ticking time bomb and requires full-time programmer maintenance. You wonder if the next feature request will become the impetus for the collapse- Then you turn into Robert Gates: "I don't know where. I don't know when. But something bad is going to happen!!!"

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

#69

Post by smt88 »

logicallee wrote: post #34
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…

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

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

#70

Post by Hupriene »

abakker wrote: post #45
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…

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.
Post reply on HN