4 ms·

I guess my default answer is: because I have to solve some business problem to get paid, and I never have enough information or time to do it right - or phrased

by csours 8y ago

I guess my default answer is: because I have to solve some business problem to get paid, and I never have enough information or time to do it right - or phrased differently: If I took enough time to do it right, someone else would have already done it wrong and moved on. Is there a "better" answer than worse is better?

cosarara 8y ago
Well I don't know if it's a "better" answer, but in my case, I didn't know about Eiffel. I had heard the name, nothing else. Maybe I'll try writing something with it now.
lkrubner 8y ago
Better is generally better than worse is better. The passive nature of worse is better postpones problems till later on. The philosophy of "worse is better" works for those who are competing mostly on price, but are you sure you want to spend your career in that category? That can be a tough life, ground down by low cost bids. Among the consultants I've known in New York, the better one's definitely avoid the "worse is better" philosophy. I'm talking about those consultants who charge in the range of $200 to $400 an hour. These people are hired to implement a "best is best" approach. I'm working on a project like that now, where we brought in one of the best AWS consultants in this region to build out a complex infrastructure, following best practices. We are pleased to see something take shape that we know is very good. Consultants of this type can not afford to be passive, because they are being paid, in part, to push pass obstacles, including political obstacles, and implement an architecture as close to idea as possible.
- pierrebai 8y ago
  The problems with that position and how your phrased it are that it is wrong, sounds condescending, is an easy way out and more importantly, completely ignores the real issue. And the real issue is time vs result. That's the essence of worse is better. It's the well documented fact of diminishing return and exponential cost of additional quality. You can deliver N features over a given fixed time. Given the urve of quality vs time, there is a true sweet spot where your maximize value, for whatever criteria you want for the value. Spending too much time on fewer items or too few time on too many will respectively waste time on unnecessary polish and deliver stoo many items of no value. There is a sweet spot.
  - pdimitar 8y ago
    > There is a sweet spot. There is, but it definitely is NOT at one of the extreme ends of the curve where experienced bean-counters will negotiate down the engineering effort (and thus money) to the absolutely minimum necessary for the project not to implode 2 days after release. Truth is, at one point in your career you have to start pushing back against those bean-counters. They will never get tired, and they are everywhere. At certain point you take a stand, put your foot down and say: "No, this will NOT be done in 2 days. It will be done in 5 and thus it won't have to be patched 10 times in the space of a week. If you don't like it, my resignation is ready." You would be surprised how often that works. Many of the business types and managers are bullies only because nobody ever fought back. ...Or you could take a more diplomatic, but still firm, stance. Like "the overall cost of this feature will be much lower if I work on this for 5 days instead of 2". But IMO that almost never flies so I became blunt with time and I simply don't care. I passed five job offers lately for similar reasons and I couldn't be happier about it.
- dustingetz 8y ago
  I've done consulting at that rate. There is selection bias in what you describe: the kind of client who will pay that rate tends to already know they want "best is better" which is why they hired the fancy consultant in the first place. I have also consulted at that rate to pre-revenue startups, a much harder sales pitch because you're literally decimating their burn. The pitch here is advancing their business to the next stage as fast as possible. For this, worse is absolutely better as they don't yet even know what "best" is. They do however know what "done, delivered your MVP in two days" is. BTW if any of you want your MVP delivered in two days, consulting portfolio is in profile.
endymi0n 8y ago
Yes. The fundamental weakness of the OPs view is that there are different types of „right“ depending on the correct tradeoffs to make. My main guide for that tradeoff is estimating how often code will be read vs. written vs. executed. All those combined plus the time it takes to do code and testing make up the total time to optimize. That way, I‘ll write exploratory code different than a prototype, which again is different to a protoduction test, a small production system I‘ll maintain myself, a large production system with different teams and software I‘ll completely hand over or open source as a library. Only an experienced engineer will realize that each of those versions of the same functionality will be „right“ in the context of their creation.
jjaredsimpson 8y ago
Worse is better could be described as "easiest sufficient approximation." But if I have a business problem with a small enough epsilon you might not get sufficiently close with your worse techniques in a reasonable amount of time. And to stretch the metaphor even more you may hit an asymphtote and never supply a solution. Doing something "right" isn't necessarily always slower. Sometimes it is the only path to an acceptable solution.
coldtea 8y ago
>I guess my default answer is: because I have to solve some business problem to get paid, and I never have enough information or time to do it right That's a red herring. People working on a business program don't need to encode the "whole information to do it right" (e.g. for the eventual version of the program when every constraint is known). Just the ones that have to hold at the time they right it, and they already know those -- from their current requirements. >or phrased differently: If I took enough time to do it right, someone else would have already done it wrong and moved on. That's also a red herring, unless you don't write tests either.
- TooBrokeToBeg 8y ago
  > unless you don't write tests either. You mean "oracles" (from the blog post). Just program correctly amirite? eyeroll If your example doesn't deal with user input, you're talking about a problem of modeling under known conditions, which is trivial and ivory tower arrogance.
  - coldtea 8y ago
    >You mean "oracles" (from the blog post). Just program correctly amirite? eyeroll I don't see the reason for the eyeroll. You'd have a point if the "just program correctly" meant "just get it right". But it's not. It's "just use contracts and invariants explicitly defined in your program, Eiffel style to check its correctness". Which is even more powerful than writing tests. >f your example doesn't deal with user input, you're talking about a problem of modeling under known conditions, which is trivial and ivory tower arrogance. Not sure how tests are anything other than "modeling under known conditions". Are the assertions in your test in any way "unknown"? If you mean fuzzing, you can do that trivially with Eiffel style programs as well. And the "tests" you do that way are there in the code, available in the debugger, and so on.
    - pdimitar 8y ago
      Can you give a practical example on how to encode invariants explicitly in a more popular language? As for contracts, basically 99% of the languages have some form of the Java interfaces, or Elixir behaviours/protocols, or LISP's several ways of doing it. But for invariants, I would appreciate an example if you are willing to provide one.
junke 8y ago
My problem with the slogan is that it has become a catch phrase for those who either haven't read the original article, or have read it and either have forgotten what it really talked about or never understood it in the first place. As a catch phrase, it is often used to justify shoddy design, or following the crowd rather than doing what is right, or as short-hand for the real claim that our customers are too stupid to either appreciate or deserve high quality products. Why spend the time doing things right, this line of reasoning goes, when we all know that worse is better. You are far better off giving the customer something that you know is less than what you could produce, because they (those simple customers) will think that it is better. Worse is Worse (Jim Waldo) https://www.artima.com/weblogs/viewpost.jsp?thread=24807 https://www.artima.com/weblogs/viewpost.jsp?thread=24807
- mmt 8y ago
  That's just a summary of an interpretation of the original (a copy of which he links to): https://www.jwz.org/doc/worse-is-better.html https://www.jwz.org/doc/worse-is-better.html (Be sure to copy-paste to avoid jwz's HN referer-trap) This line also appears just before that paragraph: > Of course, worse is better is a much catchier slogan than better depends on your goodness metric Ultimately, this seems to be applicable even to this discussion, where one goodness metric is "correctness" and another goodness metric is "expediency". In the original essay, it's simplicity of implementation rather than expediency, but I'm not sure that's all that huge a conceptual difference here (other than for the purposes of a slippery slope argument).
pmoriarty 8y ago
Worse is better doesn't sound so bad for just a single (small) project. Where it starts to go badly off the rails is when there's a company culture of worse is better and one quickfix, bandaid solution is piled on top of another. They then wind up with one or more Leaning Towers of Pisa made up of bandaids, hacks, and quick fixes, and everyone running around like headless chickens putting out fires and trying to bandaid all the failures as the towers are constantly in the process of collapsing. This leads to an ever widening spiral of hacks upon hacks upon hacks as company culture, lack of manpower, and pennypinching never gives them the luxry of doing it right, and cutting the gordian knot by scrapping everything and doing it right from the start becomes ever more impractical.
- LandR 8y ago
  This is a depressingly accurate description of my life :(
- gowld 8y ago
  The whole web is "worse is better". You can say "worse is worse", but that implies you think the web is worse than something that.. what, would have sprung into existence if the current web was suppressed?
  - icebraining 8y ago
    Project Xanadu?
- ryrobes 8y ago
  Sadly - this is virtually ALL companies over size X, age Y. The dirty "silos" outnumber the clean by far.
dimman 8y ago
I think the phrase you’re looking for is: good enough.

by csours 8y ago

cosarara 8y ago

Well I don't know if it's a "better" answer, but in my case, I didn't know about Eiffel. I had heard the name, nothing else. Maybe I'll try writing something with it now.

lkrubner 8y ago

Better is generally better than worse is better. The passive nature of worse is better postpones problems till later on. The philosophy of "worse is better" works for those who are competing mostly on price, but are you sure you want to spend your career in that category? That can be a tough life, ground down by low cost bids. Among the consultants I've known in New York, the better one's definitely avoid the "worse is better" philosophy. I'm talking about those consultants who charge in the range of $200 to $400 an hour. These people are hired to implement a "best is best" approach. I'm working on a project like that now, where we brought in one of the best AWS consultants in this region to build out a complex infrastructure, following best practices. We are pleased to see something take shape that we know is very good. Consultants of this type can not afford to be passive, because they are being paid, in part, to push pass obstacles, including political obstacles, and implement an architecture as close to idea as possible.

pierrebai 8y ago
The problems with that position and how your phrased it are that it is wrong, sounds condescending, is an easy way out and more importantly, completely ignores the real issue. And the real issue is time vs result. That's the essence of worse is better. It's the well documented fact of diminishing return and exponential cost of additional quality. You can deliver N features over a given fixed time. Given the urve of quality vs time, there is a true sweet spot where your maximize value, for whatever criteria you want for the value. Spending too much time on fewer items or too few time on too many will respectively waste time on unnecessary polish and deliver stoo many items of no value. There is a sweet spot.
- pdimitar 8y ago
  > There is a sweet spot. There is, but it definitely is NOT at one of the extreme ends of the curve where experienced bean-counters will negotiate down the engineering effort (and thus money) to the absolutely minimum necessary for the project not to implode 2 days after release. Truth is, at one point in your career you have to start pushing back against those bean-counters. They will never get tired, and they are everywhere. At certain point you take a stand, put your foot down and say: "No, this will NOT be done in 2 days. It will be done in 5 and thus it won't have to be patched 10 times in the space of a week. If you don't like it, my resignation is ready." You would be surprised how often that works. Many of the business types and managers are bullies only because nobody ever fought back. ...Or you could take a more diplomatic, but still firm, stance. Like "the overall cost of this feature will be much lower if I work on this for 5 days instead of 2". But IMO that almost never flies so I became blunt with time and I simply don't care. I passed five job offers lately for similar reasons and I couldn't be happier about it.
dustingetz 8y ago
I've done consulting at that rate. There is selection bias in what you describe: the kind of client who will pay that rate tends to already know they want "best is better" which is why they hired the fancy consultant in the first place. I have also consulted at that rate to pre-revenue startups, a much harder sales pitch because you're literally decimating their burn. The pitch here is advancing their business to the next stage as fast as possible. For this, worse is absolutely better as they don't yet even know what "best" is. They do however know what "done, delivered your MVP in two days" is. BTW if any of you want your MVP delivered in two days, consulting portfolio is in profile.

endymi0n 8y ago

Yes. The fundamental weakness of the OPs view is that there are different types of „right“ depending on the correct tradeoffs to make. My main guide for that tradeoff is estimating how often code will be read vs. written vs. executed. All those combined plus the time it takes to do code and testing make up the total time to optimize. That way, I‘ll write exploratory code different than a prototype, which again is different to a protoduction test, a small production system I‘ll maintain myself, a large production system with different teams and software I‘ll completely hand over or open source as a library. Only an experienced engineer will realize that each of those versions of the same functionality will be „right“ in the context of their creation.

jjaredsimpson 8y ago

Worse is better could be described as "easiest sufficient approximation." But if I have a business problem with a small enough epsilon you might not get sufficiently close with your worse techniques in a reasonable amount of time. And to stretch the metaphor even more you may hit an asymphtote and never supply a solution. Doing something "right" isn't necessarily always slower. Sometimes it is the only path to an acceptable solution.

coldtea 8y ago

>I guess my default answer is: because I have to solve some business problem to get paid, and I never have enough information or time to do it right That's a red herring. People working on a business program don't need to encode the "whole information to do it right" (e.g. for the eventual version of the program when every constraint is known). Just the ones that have to hold at the time they right it, and they already know those -- from their current requirements. >or phrased differently: If I took enough time to do it right, someone else would have already done it wrong and moved on. That's also a red herring, unless you don't write tests either.

TooBrokeToBeg 8y ago
> unless you don't write tests either. You mean "oracles" (from the blog post). Just program correctly amirite? eyeroll If your example doesn't deal with user input, you're talking about a problem of modeling under known conditions, which is trivial and ivory tower arrogance.
- coldtea 8y ago
  >You mean "oracles" (from the blog post). Just program correctly amirite? eyeroll I don't see the reason for the eyeroll. You'd have a point if the "just program correctly" meant "just get it right". But it's not. It's "just use contracts and invariants explicitly defined in your program, Eiffel style to check its correctness". Which is even more powerful than writing tests. >f your example doesn't deal with user input, you're talking about a problem of modeling under known conditions, which is trivial and ivory tower arrogance. Not sure how tests are anything other than "modeling under known conditions". Are the assertions in your test in any way "unknown"? If you mean fuzzing, you can do that trivially with Eiffel style programs as well. And the "tests" you do that way are there in the code, available in the debugger, and so on.
  - pdimitar 8y ago
    Can you give a practical example on how to encode invariants explicitly in a more popular language? As for contracts, basically 99% of the languages have some form of the Java interfaces, or Elixir behaviours/protocols, or LISP's several ways of doing it. But for invariants, I would appreciate an example if you are willing to provide one.

junke 8y ago

My problem with the slogan is that it has become a catch phrase for those who either haven't read the original article, or have read it and either have forgotten what it really talked about or never understood it in the first place. As a catch phrase, it is often used to justify shoddy design, or following the crowd rather than doing what is right, or as short-hand for the real claim that our customers are too stupid to either appreciate or deserve high quality products. Why spend the time doing things right, this line of reasoning goes, when we all know that worse is better. You are far better off giving the customer something that you know is less than what you could produce, because they (those simple customers) will think that it is better. Worse is Worse (Jim Waldo) https://www.artima.com/weblogs/viewpost.jsp?thread=24807 https://www.artima.com/weblogs/viewpost.jsp?thread=24807

mmt 8y ago
That's just a summary of an interpretation of the original (a copy of which he links to): https://www.jwz.org/doc/worse-is-better.html https://www.jwz.org/doc/worse-is-better.html (Be sure to copy-paste to avoid jwz's HN referer-trap) This line also appears just before that paragraph: > Of course, worse is better is a much catchier slogan than better depends on your goodness metric Ultimately, this seems to be applicable even to this discussion, where one goodness metric is "correctness" and another goodness metric is "expediency". In the original essay, it's simplicity of implementation rather than expediency, but I'm not sure that's all that huge a conceptual difference here (other than for the purposes of a slippery slope argument).

pmoriarty 8y ago

Worse is better doesn't sound so bad for just a single (small) project. Where it starts to go badly off the rails is when there's a company culture of worse is better and one quickfix, bandaid solution is piled on top of another. They then wind up with one or more Leaning Towers of Pisa made up of bandaids, hacks, and quick fixes, and everyone running around like headless chickens putting out fires and trying to bandaid all the failures as the towers are constantly in the process of collapsing. This leads to an ever widening spiral of hacks upon hacks upon hacks as company culture, lack of manpower, and pennypinching never gives them the luxry of doing it right, and cutting the gordian knot by scrapping everything and doing it right from the start becomes ever more impractical.

LandR 8y ago
This is a depressingly accurate description of my life :(
gowld 8y ago
The whole web is "worse is better". You can say "worse is worse", but that implies you think the web is worse than something that.. what, would have sprung into existence if the current web was suppressed?
- icebraining 8y ago
  Project Xanadu?
ryrobes 8y ago
Sadly - this is virtually ALL companies over size X, age Y. The dirty "silos" outnumber the clean by far.

dimman 8y ago

I think the phrase you’re looking for is: good enough.