Hacker News Reader

Comment by komali2 | Hacker News Reader

Regarding "UNPHAT": Is this... serious? Does the author genuinely hope that we will use this acronym as a means to help guide our technology choosing decisions? Is it not their creation and is just something I wasn't aware of yet?

Finally, do these forced acronyms ever help anybody else out there? I mean seriously, the "N" standing for "eNumerate?" The "P" standing for "Paper," which barely correlates to the actual meaning "consider a candidate solution."

Seems to me just saying "apply a principle of unfattening your technology decisions" would be a hell of a lot easier to remember.

View on HN

Checklists and acronyms help some people, so more power to them. But I think the central observation of most of the anti-cargo-cult articles boils down to a simple maxim of "don't use a technology unless you understand what it's bad at".

There are very few technologies that can reasonably be thought of as strict upgrades, and the few that do exist (i.e. MySQL to Postgres) tend to be incremental enough that switching rarely justifies the migration costs. Instead, many solve one or two exceptionally dramatic problems (gargantuan datasets, huge write volumes, partition tolerant master-master replication, etc.) and are willing to make equally dramatic tradeoffs to achieve it. Saying Technology X is good at Problem Y is only half the story.

In my own practice I've found that forcing myself to stop and explicitly enumerate both the pros and cons of a new technology is usually enough to get my professional intuition to kick in. And 99 times out of 100 it tells me to just use boring old SQL and move on.

Try DMAIC six sigma - Define/Measure/Analyze/Improve/Control

or OSEMN data science - Obtain/Scrub/Explore/Model/iNterpret http://www.dataists.com/2010/09/a-taxonomy-of-data-science/

I doubt it. I think it needs to be three or fours letters. (E.g. Always Be Closing. Keep It Simple, Stupid.)

---

Trying my hand:

- understand the DOMAIN

- find the OPTIONS

- research a CANDIDATE

- know the HISTORY

- consider the ADVANTAGES

- apply deliberate THOUGHT

DOCHAT

Hmm. That's a much better acronym, but it makes me come back to my original question - an acronym I guess is a way to make a process (dare I say algorithm) easier to remember, yea? So like, when you're switching to a new technology, the steps are as you listed, which are basically just

1. Understand what your problem is, and the potential solutions to that problem.

2. Use your brain.

3. Make an intelligent decision.

Or really just

1. Use your brain

I mean I just don't see the need here. Could be arrogance, I guess? Is this the very problem the author was trying to solve? Create a defined process for technology choosing?

You've just described the Feynman Algorithm.

The point of most processes is to help stupid people (or, just, people without large amounts of analytical talent) make smarter decisions than their own brains would generate. Processes "raise the waterline" of an organization's aggregate behavioral intelligence, by ensuring that the stupid-est decisions being made are no more stupid than the process.

Processes also frequently serve as checklists, to ensure that smart people aren't being temporarily stupid—"did I check that I have all my surgical tools before closing?" and such.

Maybe simpler:

DOE

Don't Over Engineer

(which more or less brings us back to KISS principle)

I like DOE because the inverse is E (Engineer). It illustrates an on going challenge in technology where the first question isn't "What capabilities should our resulting systems have? And what constraints are there on our implementation?" (which would be engineering a solution) instead we get the question "What other systems out there seem to solve this problem?", or worse "What other systems have similar inputs and outputs to the ones we have and want?"

Also there is this other question (as I see it):

What CAN this (pre-chosen) something (insert here hardware or tool or programming language or library) do?

Let's use ALL (or most) these functionalities! (because we CAN)

Losing sight of the actual question which should be "What is actually needed"?

>DOE

Can be confused with Do Over Engineer.

>>DOE >Can be confused with Do Over Engineer.

YSNOE (You Shalt Not Over Engineer) which is more imperative is worse at reading.

Maybe NOE (Never Over Engineer) would be acceptable.

It seems to me just a complication of YAGNI.

YAGNI is dismissive. That other approach with a comparably silly acronym is an actually useful checklist.

GARABA!

Reply on news.ycombinator.com