How to Destroy the Myth of the Proper Solution | Hacker News Reader

How to Destroy the Myth of the Proper Solution

hackernoon.com

53 pointsendswapper25 comments

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.

AKA The Nirvana Fallacy

https://en.wikipedia.org/wiki/Nirvana_fallacy

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

> If we're aware that the Proper Solution is impossible to be achieved, we can at least try to get as closer as possible to it given the current knowledge or circumstances of an individual or team.

From the article.

At first I found objection with this blog post. But as soon as I replaced "proper" with "perfect", I loved it.

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

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.

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

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.

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.

I agree with #1, but #2 is often used to defend under investment in a project. 15 years ago it might have been an adequate solution, but the lack of adequate maintenance and improvement is what makes legacy today.

I'm also amazed at what some people consider a "functional system". Frequent downtime and developer/support intervention is not what I'd consider functional, but for many business it is.

That's the definition "Proper Solution" should have.

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.

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.

I bet half of what looks like slap-dash in retrospect is actually attempts to achieve perfection too soon by being uninformed (of the tools, or of the requirements, or of the environment the solution must exist in).

Either way, what you end up with is technical debt.

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

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?

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.

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.

If your architect isn't responsible for the code and doesn't know the product nor the business case, maybe he shouldn't be the architect?

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.

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.

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.

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

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

Great is the enemy of good enough

Reply on news.ycombinator.com