
How to Destroy the Myth of the Proper Solution - endswapper
https://hackernoon.com/how-to-destroy-the-myth-of-the-proper-solution-94ca958def1f
======
unabst
Isn't what he describes "the Perfect Solution" problem? In politics, it's used
to block any progress by attacking the fact that the solution is not perfect.
Obama talks about it often in relation to getting things done. Even if he
wanted single payer healthcare, faced with it being impossible, he does the
next best thing. His adversaries would blame him for an imperfect solution,
but so would many of his supporters. Though there are things that he hasn't
made progress on, I'd say overall his method works.

I'd take "proper solutions" to mean "nothing improper" which, to my
understanding, is an extremely practical and feasible design goal for quality
control purposes. Proper solutions definitely exist in this context.
Encryption, handling user input, speed optimizations are good examples.

I'd go further and say, if a solution is proper (not wrong), and progressive
(makes something better), it's good enough. Maximizing the better part might
be subjective yada yada, but better is measurable, and there is no need to
introduce the "proper" problem when dealing with the "better" problem.
Whatever "better" that needs to get done should get done "properly". Isn't
that what we're all already doing?

And of course, nothing is ever perfect. But it's a good moving target.

~~~
rhizome
AKA The Nirvana Fallacy

[https://en.wikipedia.org/wiki/Nirvana_fallacy](https://en.wikipedia.org/wiki/Nirvana_fallacy)

~~~
fagnerbrack
Is that basically using Straw Man to build a solution that is too far from the
achievable one?

------
Spearchucker
Took a while for me to work out that the perfect/proper/best solution doesn't
exist. Took a while to work out what does exist. It goes like this (note that
desired outcome starts with worst case at the top of the list, and ends with
best case at the end):

Technical depth and breath + domain expertise = the best solution

The above + policital acumen = a good solution

The above + stategy = the right solution

The above + leadership = a successful solution

Anybody can obtain technical depth and breadth. Bit of training, bit of
time... Technology is easy. _People_ are hard. So these days I aim to be
successful, and try daily to improve the soft skills listed above to make sure
I can do that.

------
gravypod
> There's no such thing as the "Proper Solution", there's only the best
> solution we are able to come up given the current knowledge and
> circumstances

I think that is the definition of a "Proper Solution".

Another way to define a "Proper Solution" is: the fastest solution that still
manages to be maintainable while meeting all of the requirements for the
project which is not "over-engineered".

I think that's the broad-spectrum "proper solution". I don't think there is
any application that wouldn't want to meet these requirements.

~~~
rm999
There are two places I see the fallacy frequently pop up:

1\. Over-engineering. This often comes in the form of trying to perfect
something before releasing it, and/or long projects with fluid, changing
requirements.

2\. Criticizing old code/systems and their developer without any understanding
of the context and trade-offs made at the time.

In my experience the first is common and the second is even more common. The
worst is when #1 and #2 combine into someone trying to replace a functional
system with an improved "v2" that is more complicated and no better.

~~~
50CNT
I think #2 is aggravated by lack of documentation. How would any new developer
ever understand the context and trade-offs made at the time if they were never
written down? If there's no records, it's either reverse engineering, or re-
engineering.

------
Ericson2314
I dunno, we live in a era of technical debt. Calling out hubris over claiming
something perfect is not my priority when so much known slap-dash abounds.

~~~
cheriot
That's fair, but I think the article's point is, too. It's really easy to make
perfect and proper the enemy of incremental improvement and shipping product.
The "right" solution requires X that's always three months off. Discussions
derailed by someone's need to describe the "right" solution that they know
doesn't apply to this situation, but it's the cool thing on the internet and
we "should" do it. There's value in framing a discussion.

------
disposablezero
Learning, effort, team rapport, enjoyment, cost and time: choose up to n ∈
Reals, n > 0, using a Poisson distribution where λ = 1... but usually do
without all of them and fix legacy code yesterday and make it pretty... oh and
change everything again, right now. (Tension of fine-tuning to apparent/actual
needs with what's possible... Office Space/Dilbert vs. the few whom bring
customers nearer to the tight iterations and visible progress of actual agile
shops making something gradually useful, fairly quickly. In traditional
offices, there is a core insecurity of not appearing incapable or making a
mistake, so big deliverable guesswork fails to meet requirements or stay
within time/cost budget, and "do what the boss says". Also, random vendors
taking forever and doing almost "nothing" because they were not milestone
deliverables but charge by the hour, no customer-side PM usually.)

------
fma
My architect loves the "perfect solution" even if it means a butt ton more
work. In times where he is wrong, he will fight to the death his solution
(which is the only valid solution).

He's not the one that maintains the code. He's not the one that knows the
product, or business case in detail.

If I disagree with him he will throw some random fact out which may not have
much weight. If I say, well your solution will take three additions weeks to
implement and does not buy us more and is less performant. He would say the
equivalent of...the sky is blue.

Does anyone else have this issue, and know how to counter back?

~~~
resonantjacket5
Well it seems like (I'm guessing here) your architect is trying to say that
his solution will hold up better in the long run.

In terms of arguing, if you guys are going around in circles one good way is
to write down the key points of the argument or merits on a whiteboard/paper.
Like solution one offers 1) speed 2)cheap versus solution two offers 1)
stability or something. I've always found that people good with talking, but
have a vacuous argument tend to break apart when it is laid out in writing.

~~~
fma
Yeah a lot of his arguments are for long term solution, the "perfect
solution".

Real life example from last week. We needed quick turnaround for a JMS cluster
to fix a P1 incident that has been haunting the business for a few weeks. Our
other applications use file based persistence store on its own NAS.

I proposed we used JDBC backed persistence store - use our existing DB and
just add the scheme. I work in a huge company, so new infrastructure for the
NAS takes a while to get.

He was against it, said JDBC store is not performant. He wanted a new NAS, and
the JMS cluster had to have its own dedicated resource, and not use the
existing one (which my teammate proposed and was shot down by him)

That application would have a max of 10 messages on that queue per day to
trigger a process...no performance needed really.

Forward to the next day, when he proposed his solution to operations. He got
chewed up by another architect and the operations guy for a solution that
requires a whole new NAS. They settled on using an existing NAS.

Quite a bit of details, hope my coworkers don't browse HN.

------
dkarapetyan
There are indeed proper solutions. Bridges need to withstand certain weather
conditions, skyscrapers need to sway in a certain way, and software systems
need to operate with certain requirements like transactions per second,
latency limits, memory bounds, etc. Saying proper solutions don't exist is
just an excuse for hackers to ship broken products.

If you consistently can't ship proper solutions then either your design
process is broken or the problem is between the chair and the keyboard. There
is no myth here.

~~~
twic
I think the author's objection is to the idea of _the_ proper solution, the
one perfect solution that can't be improved on. Such a thing might exist, but
what you almost always need is actually an adequate solution - bridges that
don't fall down, even if they aren't the perfect bridge, etc - so time spent
chasing that golden ideal is wasted.

------
dpweb
It's really about maximizing value/cost. A large portion of software is
created for and funded by commercial purposes and usually, they care about
nothing besides cost and results. For instance, what stack we are using, they
could care less. Not your technical manager, I'm talkng about the execs that
allocated the budget so that you have a job. Obviously at Google they would
care higher up the chain than at Wells Fargo.

As engineers we value efficiency for its own sake as we see the beauty in it
and so serve the same goals as our corporate bosses. We were directed to pre-
package these optimal end-products. Of course, it failed. But have found
greater success in standardizing not the solution, but the process we do to
find the best solutions.

------
gabrielgoh
So basically the aphorism "perfect is the enemy of the good".

------
msane
On a related note, I think people should tone it down on calling their pet
processes a "best practice".

------
Dowwie
Great is the enemy of good enough

