I think today it's more useful to think of most software as a living organism interacting with it's environment - it's constantly evolving and adapting to external changes (user needs, dependencies, 3rd party services etc.).
Code Is Never “Perfect”, Code Is Only Ever “Good Enough”
11–20 of 130 posts
Re: Code Is Never “Perfect”, Code Is Only Ever “Good Enough”
#12I have the start of a lightning talk on something similar, called "Why Software Sucks". The idea is that we only make software good enough to get by - we will always choose features over robustness if we possibly can. Every project ends when it either fails, or hits feature-complete. No one sits around polishing the pile of bugs and bad decisions that is a feature-complete app unless they have to - much more fun to s…
It seems like most consumer apps incur a crazy amount of technical debt while largely paying people in equity, then if they take off raise a bunch of money to pay other people in cash to sort it all out... Pretty good system actually.
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-work-land, but that's not the same as robust! So software - all software - hovers around that barely-works/doesn't-work borderline.
Re: Code Is Never “Perfect”, Code Is Only Ever “Good Enough”
#13I wonder if this attitude will change once things like coq become more accessible.
Agreed. I find that when working in some functional systems like haskell/clojure or even functional-style javascript, I do occasionally produce code of reasonable complexity that I call pretty much perfect.
Re: Code Is Never “Perfect”, Code Is Only Ever “Good Enough”
#14I 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 perfect!). That usually involves finding the mathematical meaning of the abstractions you're using. (Shameless plug- I wrote a little blog post on the subject: http://asivitz.com/posts/programming_in_haskell)
Re: Code Is Never “Perfect”, Code Is Only Ever “Good Enough”
#15Re: Code Is Never “Perfect”, Code Is Only Ever “Good Enough”
#16I hope this attitude is used sparingly and in cases where either the problem is supremely hard or where time is exceedingly short.
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 perfect solution might be.
Re: Code Is Never “Perfect”, Code Is Only Ever “Good Enough”
#17One 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 anything. There is little reward in maintenance.
“Good enough” is really the type of attitude that leads to this unfair balance of effort.
Unfortunately, we live in a world where criticism is levied very heavily on where you are now, and not on how you got there. What, version 2.0 of the product sucks now? Screw it, “1 star”, boycott this; fire the team responsible! Never mind the fact that version 1.0 was a rickety mess, all of those guys left, and anyone would be lucky to get the thing working at all, much less in a way that does not introduce any new bugs.
One of the big benefits of open-source is having a chance to understand what’s going on. Would as many people invest in a product, despite promising behavior in version 1.0, if they could see a critical review of how that version was actually implemented? Ideally, we can see not only how a product appears to work, but how well-engineered it is according to experts.
Re: Code Is Never “Perfect”, Code Is Only Ever “Good Enough”
#18Earlier 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.
News at 11: winging it is less work than being careful! (Of course, the situation gets fuzzier when you must account for other factors: work/dollars/lives lost due to bugs in dependencies, the integral of maintenance costs over time, etc.)
Right. The tools don't need to be easier than competitors, they just need to be easy enough and provide enough benefit that doing it another way isn't worth it.
Re: Code Is Never “Perfect”, Code Is Only Ever “Good Enough”
#19I hope this attitude is used sparingly and in cases where either the problem is supremely hard or where time is exceedingly short.
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 optimizing prematurely can be paralyzing but the other extreme where one refuses to do back of the envelope calculations and wilfully writes code that will be slow is damaging as well.
Re: Code Is Never “Perfect”, Code Is Only Ever “Good Enough”
#20Does the work of Charles Simonyi and intentional programming change this?