Is there a "better" answer than worse is better?
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.
The dirty "silos" outnumber the clean by far.
Worse is Worse (Jim Waldo)
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.