
Anyway, stop recommending bazookas to kill flies in programming - kiyanwang
https://itnext.io/anyway-stop-recommending-bazookas-to-kill-flies-in-programming-65f13439be3d
======
kstrauser
I'm not convinced. While I've been on the receiving end of such suggestions -
and yes, it can be frustrating - a lot of times the question itself reveals
problems with the intended solution.

Examples:

"Hey, our home-grown queueing service slows down when we have more than 1,000
insertions per second. How do I make its SQLite backend more scalable?" "Um,
perhaps that's not a good solution to your problem." "Would you please just
answer the question?"

"Our service can only process one request at a time, so we're thinking of
switching from Python to Rust." "Would it make more sense to make your current
system multi-threaded?" "Are you gonna help us rewrite this or not?"

Sometimes lack of experience makes suggestions seem like bazookas when they're
really cork guns. If you've never used a client-server database, that might
seem like a scary upgrade from SQLite. In reality, it's very straightforward
and common. If someone recommends a bazooka to you, first make sure that it's
actually overkill and not the standard upgrade path from your current
situation.

Further reading:
[https://en.wikipedia.org/wiki/XY_problem](https://en.wikipedia.org/wiki/XY_problem)

~~~
Doxin
While you have a point, some people seem to think that _everything_ is an XY
problem. Sometimes I just want to ask a question and not shoot down a hundred
answers because they don't understand the actual restraints I've got.

------
hprotagonist
The post’s observation is true.

“your entire idea is cruising for a bruising, trust me i’ve been there and got
the t-shirt, for the love of god please use this thing instead” is _also_
true.

Choosing which one is most true is, as usual, a judgement call. Pick the
subject matter experts that have earned your trust and respect their
judgements enough to at least think it over.

------
vortico
I think the solution to this problem is for the "asker" to know how to respond
to these recommendations. I honestly don't have good advice for this, so I
usually just do this.

"How do I list a directory with C++ without external libraries?"

"Use Boost"

"Sadly this is not possible due to the requirements listed in my question."

~~~
eschaton
Sometimes the asker is wrong in what they’re asking, or barking up the wrong
tree. In the example you give, unless the C++ Standard Library has changed
since I last used it a number of years ago, a strict interpretation of your
question gives the answer “You can’t;” the person suggesting Boost was trying
to be helpful without calling you out as asking an unreasonable question.

The person asking a technical question should always include the goal they’re
actually trying to achieve, not just the technical step they think they need
to accomplish to get there. Otherwise they won’t actually get the best help
possible.

~~~
vortico
There are two correct answers: Use std::filesystem on C++17, or rename() on
POSIX and MoveFileExW() on Windows (which are what boost::filesystem calls
internally).

These answers are correct because they answer the question literally, and
someone can extract accurate, useful information from it. If there was no
correct answer, the answer should be "you can't" from someone confident enough
to make that claim. I agree that it is good for the asker to somewhat
demonstrate that their question is asked correctly to avoid the XY Problem,
but more times than not, the reason they're trying to achieve something in the
way they ask it is so incredibly boring, it does nothing but distract from the
original question. For example, "I need to rename a file and I'm writing a C++
project for my boss, and we need to distribute this package on a cluster
managed by an external IT team that runs a build script on our code that pulls
everything from a proxy, where each file needs to be approved by another team,
and this needs to take place as quickly as possible because the machines are
wiped weekly and someone needs to monitor the build process, so it makes
everyone's lives easier if we don't pull in libraries, blah blah blah."

It's 100x easier to just say "I need to rename a file on C++. Constraints: no
libraries". When I see a question phrased this way, I can empathize exactly
why, because the asker has an encyclopedia of information behind the question
that I don't know (or want to know), and they have kindly phrased it as
concisely as possible for an expert to quickly help them. I'm just saying that
I try very hard to avoid answering questions like "I want to do X without Y"
with simply "do Y", because as much as I think I might be helping them by
showing them their question is "wrong", I'm not. I just waste their time
making them explain the reasons behind their constaints.

------
sametmax
Example: micro services, webpack based stacks, containers, graphql,
blockchains, etc

Those are bazookas. Your 10 users/day software is the fly.

~~~
wgerard
Ehh, I somewhat agree but you're generalizing a lot.

To pick one example: containers have been invaluable for setting up
reproducible dev environments (via docker compose), even across just a few
people. It doesn't take very long to setup, and the time savings are
immediately obvious to me when we have to bring someone new onboard or install
new dependencies.

~~~
taeric
Oddly, the time saving is not obvious to me. Deploying to Java app servers was
not exactly hard to get running. And it is only in this brave new world of
docker that I have joined a team and not gotten a commit on day one.

I don't blame docker. I think. However, I do feel it enables people to move
faster with more complicated solutions where not necessarily needed.

~~~
xyzzy123
So $work did java app deployment with Tomcat and puppet at scale (>100
services). Sweet. Mostly.

3 problems, 1 is that in the unlikely event you had an external system
dependency, (say, shudder, imagemagick or really, any non java binary) you
were totally hosed, because lots of systems work needed to be done to provide
it (say, make rhel packages in corp repo plus puppet guff) and also keep it up
to date.

2 was, since it was outside the supported path, actually, you couldn’t ship
anything that _wasn’t_ Java in Tomcat, Java invoked binaries were hard, but
non Java services, even judiciously and with a super good reason were
basically impossible.

3\. Your stuff _might_ be coupled to the base operating system in some way...
which meant that the operating system patches needed to be tested against all
possible application deployments and thus patching (including kernel) became
the de-facto responsibility of the team owning the application, which lead to
major delays in patch application.

Containers mostly shift these problems around (and create new and different
problems too) rather than solving them, but my experience is that they do
genuinely shift them around in a useful way.

~~~
taeric
Amusingly, I've seen all of those problems even in the docker world. It is a
bit harder to get yourself into that spot, but for fun, just try and use a GPU
on an installation of docker from about 3 years ago. :)

That said, I do agree. It is mostly shifting things around. And if this is
where your pain point was, then you will likely like what containers can do
for you.

------
rossdavidh
I sometimes use the phrase "don't use a rocketship to pick up your groceries"
for a similar phenomenon. Many (most?) webapps are trying to do things that a
simpler web page would do just fine, and the amount of bloat that comes from
that is a real problem.

~~~
coffeefirst
Yes. All the slowest, buggiest sites I encounter every day are SPA's that
could easily be a regular old forms, especially once you consider datalist,
validation, date inputs, and other things that used to require javascript
enhancements.

~~~
yjftsjthsd-h
I recently built some web apps for fun, and it shocked me how much was already
there. Just an HTML form and a POST handler with no JS at all goes shockingly
far.

------
fredley
This totally depends on what you're doing. Sometimes you should be using the
bazooka, sometimes not.

Building a large government system, or something internal for a large company
that will have heavy and pretty-well-quantified usage, and need to be
maintainable? Hell yeah bazookas all the way down. If you know your system is
going to end up large and complex, use the more complex but well-defined
tools.

If you're not doing this, or you're even just doing a beta or prototype of the
above then don't.

Really what this is about is technical debt. Technical debt - like monetary
debt - is a useful tool that can get you where you need to be (nobody saves up
from scratch to buy their first house - they get a mortgage).

The person advocating the bazooka just doesn't want you to have any debt, in
the form of whatever hacked-together fly swat you might build to do the job
temporarily, however some debt is _a good thing_.

~~~
drngdds
>Building a large government system, or something internal for a large company
that will have heavy and pretty-well-quantified usage, and need to be
maintainable? Hell yeah bazookas all the way down.

Sure, but that's not a fly.

------
7sigma
My rule of thumb is this: Does the solution solve more problems than it
creates?

Taking the example of Vue.js, I found that it makes building UIs a lot easier.
But I found that you do need to understand its caveats and its limitations
(e.g. limitations in its reactivity system). On balance, it does solve more
problems and those limitations are really minor and well documented.

But before I embraced it, I spent some time experimenting with it, assessing
the documentation, the community, ecosystem, etc...

I think this is a skill onto itself that comes with experience. I remember
jumping on the "cool" bandwagon many times, only to realise I was basically
wasting a lot of time switching to cool new technology X.

Nowadays, if I can't understand the problem something is trying to solve, it
probably means I don't have that problem.

Edit: added "limitations in" its reactivity system.

------
userbinator
I feel like there are two categories of developers, one which has "framework
envy" and loves trend-chasing with the latest and most complex technologies,
while the other values simple and straightforward solutions. Sadly, the former
seems much bigger (although it could just be because they're louder.)

Related:
[http://discuss.joelonsoftware.com/default.asp?joel.3.219431....](http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12)

------
karmakaze
I fully agree. I've learned to auto-filter by skipping over these but haven't
put in effort to post corrections because I'm still looking for the answer. If
I happen to come to an answer I particularly like, sometimes then search for
top hits and add a reference to it.

Similarly, another pet peeve is using npm modules for simple one-off tasks
like a single string manipulation function. Self written code has no options
you don't need or a nest of subdependencies.

------
fouc
I think the article has a good point about how so many tend to harp on the
most popular tools, even if they're actually overkill or unnecessary.

------
twiss
Of course, often the honest answer is "I don't know the solution to your
issue, and finding it would take me X hours of debugging (assuming
StackOverflow doesn't know the answer)." So you should probably say that
instead, perhaps with some pointers on how you'd go about said debugging.

Worse, depending on the size of the project, switching to a different tool
just to fix one hard-to-debug issue might _genuinely_ be the easiest option.
Of course, doing so without at least trying to debug the issue at hand is
slightly insane.

------
wemdyjreichert
Stack overflow is terrible about this. If I'm asking, I've already considered
options. Any better place to ask?

~~~
tqkxzugoaupvwqr
You can partially prevent unwanted/unhelpful answers by explicitly stating in
your question post that you cannot do x, y, z for reasons a, b, c.

~~~
jaclaz
Yes, generally, on stackoverflow (but not only) "going astray" replies are
actually due to both:

1) responders that either have not read fully the question or not knowing the
actual answer decide to suggest _something else_ that they know (or believe)
would work

2) badly asked questions, sometimes it is a good thing to be synthetic when
asking, but sometimes providing an even minimal background and particularly
listing what attempts have been done before make a better question

------
m3mpp
Then stop web development all together. Web dev is the story of using a
bazooka to kill flies...

------
fouc
>OMG, is Vuex the only way to share state between components? Fucking no!

Same for Redux

