[HN Gopher] Why Don't You Use
___________________________________________________________________
Why Don't You Use
Author : janvdberg
Score : 147 points
Date : 2022-03-21 16:16 UTC (6 hours ago)
(HTM) web link (www.brendangregg.com)
(TXT) w3m dump (www.brendangregg.com)
| dasil003 wrote:
| There's something infuriatingly help-vampirish about asking any
| question of the form "why don't you do x?".
|
| The pithy answer is because of all the things in the world that
| someone might propose need doing, I can only do a vanishingly
| tiny fraction of them. Even the largest, most profitable company
| in the world can only do a slightly larger tiny fraction of them.
|
| The reason we don't do the things you ask about is because we are
| focused on doing the things which we've prioritized using our
| best judgement. The idea that we somehow owe an explanation to
| internet randos about everything we _don 't_ do is indicative of
| a personality that must not be allowed anywhere near engineers
| with work to do.
| tchalla wrote:
| Honestly, I have learnt to reply with we think Y was the best
| option to bring the discussion back on track. In the case where
| the person insists to try X, I ask them - How would you do it?
| More often than not, the conversation ends there. If not, I ask
| the to make a proposal and convince the team to do X.
|
| The question of that form is akin to "proving a negative"
| gkop wrote:
| Infuriating indeed. It's not just internet randos though, it's
| also (for example) engineering executives lacking in self
| awareness.
| tapas73 wrote:
| Internet randos, executives. Next in line should be fellow
| programmers "Why the f should I tell you my reasons, if you
| are competent programmer you should allready know
| everything".
| edgyquant wrote:
| I've asked other engineers a question in this manner, but I was
| genuinely curious. E.g. why did you implement this this way
| etc.
| ape4 wrote:
| I don't want to rewrite my app when the framework/API inevitably
| changes.
| thrashh wrote:
| Personally I don't think it's actually secrecy.
|
| I think it's that you're asking the wrong person most of the
| time.
|
| From my experience, a lot of the times it's just a few people who
| really are deciding and everyone else is just part of the
| meetings and they don't really care that much.
| AdmiralAsshat wrote:
| Ctrl+F: legacy
|
| > Phrase not found
|
| Aw, come on.
| loudmax wrote:
| I believe that the kind of company that Brendan Gregg would work
| for would have excellent reasons to use or not to use a
| particular piece of software. There are a great many more
| companies that don't hire people of Gregg's caliber, and a lot of
| them are quite likely to have many terrible reasons for using not
| using a particular piece of software. Not being aware of the
| product being among those reasons. By definition, most workplaces
| are mediocre.
| justin_oaks wrote:
| Yes, I believe most companies have poor reasons for the
| technology they use.
|
| Gregg says:
|
| > People think it's poor technical choices ten times more than
| it actually is.
|
| I'm skeptical. My experience shows that technical choices are
| often driven by politics:
|
| - The boss knows the people selling the software so he chooses
| it based on that
|
| - The boss used this software in the past and he wants to stick
| with it
|
| - Penny pinching (Superior software is more expensive)
|
| - The boss who chooses the software doesn't have to use it.
|
| - We get this software for free because it is included in
| another contract. We might as well use it...
|
| And many other bad reasons.
| a_c wrote:
| Quick searching doesn't yield my "why don't you use" - migration
| cost. Unless a tool is bringing in functions never used before,
| e.g. Jira to a team where project management was non-existent,
| otherwise there are at least data , user behaviour, integration
| and reporting that need to migrate from. That means most of the
| time it just isn't worth it
| oriolid wrote:
| This is how we had people using CVS in 2010 and Subversion in
| 2020, and why we can never get rid of autoconf.
| bitwize wrote:
| (robot voice) Why don't you use MongoDB. MongoDB is web scale.
| Relational databases don't scale because they use joins and write
| to disk.
|
| (At the worksite I've been known to say "MongoDB is web scale" in
| a robot voice to remind coworkers to stop and think about whether
| Mongo (or any noSQL solution) really is the best choice or
| whether they chose it due to convention or fashion.)
| gqewogpdqa wrote:
| Oracle V2 was known as the "roach motel of databases". Data
| went in and it didn't come out. By V5, Oracle was a solid
| database. Why do people not give MongoDB the credit for growing
| up from a memory-mapped db to something far more serious, where
| they say they have ACID transactions, HA, a managed cloud
| service, etc? The industry memory of that meme is impressive,
| hilarious...and misplaced.
| lliamander wrote:
| Curiously, this doesn't include the most common reasons I've
| seen:
|
| 1. Because we our engineers don't know X, and we wouldn't be able
| hire people who already know X.
|
| 2. Because we are already invested in Y, and the benefits of X
| are nebulous and speculative, or can't be connected clearly to
| business outcomes.
|
| In essence, both of these come down to a matter of organizational
| inertia, but that inertia can either be good or bad.
|
| A lot of times, organizations don't really have a process to
| proactively evaluate technology, and the process for making
| technology changes is ad-hoc. Even when there is a clear need to
| make a change, it's not clear who all the stakeholders are or who
| makes the final decision.
|
| Ideally this is something that should be sponsored by senior
| technical leaders (CTO, VPE, etc) but the decisions should be
| made by your most senior, boots-on-the-ground technologists.
|
| (Or you can just individuals/teams to use whatever tech they
| want, with thr understanding that they have to be good citizens
| with regards to maintenance, documentation, tooling, etc.)
| HeyLaughingBoy wrote:
| > Technology X may be too expensive because we're using another
| technology with a special discount that's confidential.
|
| I'm really proud of myself that I didn't insta-rage upon reading
| this one. Couple years ago, as the software project lead, I
| suggested a number of processor technologies for a custom device
| for a specific customer. Any of them would have worked well, they
| were all very well documented and popular and most of them we
| already had experience with.
|
| Which one did the company owner go with you ask? The obscure,
| brand new processor that we had never used, lacked documentation,
| manufacturer-supplied sample code was either full of bugs or only
| showed how to use the features in the most brain-dead, trivial
| fashion.
|
| Why you ask? Well, it turned out that we were some kind of
| "technology evangelist" for that semiconductor company and we got
| a substantial kickback for just putting one of these chips into a
| new design.
| buescher wrote:
| Two potential answers he left out:
|
| - It ships/deploys next month and you'll find out then
|
| - We've been shipping/using it since 2014 and you really should
| do your homework
| em-bee wrote:
| how about: it doesn't solve a problem that we
| have.
|
| if a tool that i am not using doesn't solve any real, urgent,
| important, serious or whatever problem, then most likely the cost
| to switch is going to be greater than the potential gain.
|
| it is of course important to actually understand what the real
| problems are, instead of what they are imagined to be to avoid
| solving the wrong problems.
|
| most real problems are measured in cost, lost revenue, reduced
| profit.
|
| beyond that there are only a few more important reasons:
| user/developer satisfaction and security.
|
| if your suggestion does not affect those then it's probably not
| important.
|
| if there is something that makes developers happier, then they
| are probably already using it. (unless they work in a company
| with lots of red tape and the answer to the question in the
| headline is: because we we can't (for whatever reason.))
|
| and i mention security separately, because while it is a real
| problem, it often doesn't affect revenue/profit (until something
| happens)
|
| the point is, i don't ask why companies don't use something that
| i think would be better. you do you. but if you present me with a
| problem that you'd like me to solve then i'll tell you what i
| think you should change (and then i won't ask)
| swatcoder wrote:
| > I used to be the outsider asking the big companies, and their
| silence would drive me nuts. Do they not know about this
| technology? Why wouldn't they use it?...I finally get it now
| having seen it from the other side. They are usually well aware
| of various technologies but have reasons not to use them which
| they usually won't share.
|
| I can't speak for the OP, but this insight often just comes with
| experience and rarely needs seeing it "from the other side".
|
| With some exceptions, the reality is that most technologies
| aren't introducing a new class of tool.
|
| They're not contributing a wrench to a world that had only seen
| hammers and screwdrivers, let alone a power drill or industrial
| crane. The innovations they contribute are more incremental than
| a lot of early-career developers realize: they're a wrench with a
| more ergonomic handle, or a hammer with a claw on the back.
| They're a power drill with a simpler way to change bits.
|
| If your organization already knows how to do its job with some
| other style of wrench or hammer or power drill, there are many
| reasons you _might_ pick some new one, but few reasons you
| _should_ pick any particular one at any particular time.
|
| Articulating an answer to "buy why not?" is usually just an
| exercise you perform for the benefit of juniors, outsiders,
| marketers, evangelists and people who happened to be used to that
| tool already.
| totaldex wrote:
| These effectively boil down to ROI - it's tricky to quantify
| what return a tool will give, but its even harder to quantify
| the cost of switching over. At a big enough company, most will
| shudder at the thought of a massive migration without an
| equally passive payoff.
| henning wrote:
| Yes, especially if your entire universe of possible choices are
| almost identical to what you use now, by definition, everything
| under consideration offers no new ideas. Anything with actual
| new ideas is automatically excluded without consideration. This
| lets old farts talk about "picking the right tool for the job"
| and not realize how incredibly narrow-minded and intellectually
| dishonest they are.
| makapuf wrote:
| Well often the really old timers ( still in tech, so survivor
| bits here) have seen several waves of tech and know some
| qualities can withstand the test of time, and other fads will
| not. And having seen the previous fad come and go, they often
| are less attached to it than the ones that grew with only it,
| accepting some of the real benefits of the new tech.
| RealityVoid wrote:
| But, sometimes, a lot of times... It's just "the way we do
| things here". Some companies really are insulated from outside
| inovation.
| alar44 wrote:
| That and sometimes the connectedness of their tools means
| that switching to some new technology means opening a massive
| can of worms. I've moved my company over to M365 but we are
| going to continue to use Slack rather than Teams due to the
| sheer amount of bots and integration we have set up in Slack.
| It's just not worth the time to re-engineer for the marginal
| benefit.
| bjelkeman-again wrote:
| That feels like you dodged a bullet based on how I
| experience using Teams vs Slack.
| alar44 wrote:
| I disagree completely. If you're bought into the M365
| ecosystem, Teams is fantastic, everything is in one spot.
| jmtulloss wrote:
| There's a corollary here for engineering managers managing a new
| (to them) team. With the caveat that they must be very clear that
| they trust the team and are there to learn, "why don't you do X"
| is incredibly valuable for a manager to connect their limited
| experience with the deep experience on the team. The reasons
| often fall into one of three categories:
|
| - X is not a good solution outside of internal considerations
| (what this article mostly focuses on)
|
| - X is a good solution but not worth it for a good list of
| reasons (ie it makes slightly different tradeoffs than the
| internal solution and the cost of switching is higher than the
| benefit of changing tradeoffs)
|
| - X is better than what the team is currently doing but the team
| hasn't been able to get buy in for the investment needed to
| change to X
|
| All of these scenarios are great for the manager to understand,
| but the last one is the manager's dream because they actually
| have a concrete opportunity to help the team!
| tchalla wrote:
| Personally, a better framed question which works for me is -
| "What options did you consider and how did you choose this
| option?"
| fossuser wrote:
| When I've asked this question to engineers that work at famous
| companies they're usually happy to explain what the tradeoffs are
| and why some decision was made if they know the reason (often
| there might even be a blog post).
|
| Usually they just don't know the reason unless it's within their
| specific team or area of expertise and they just say they don't
| know.
|
| Maybe it's different at the executive level or something.
| [deleted]
| [deleted]
| sergiomattei wrote:
| I find this article pretty pointless. People are curious, nothing
| new.
|
| If you're tired of explaining to satisfy their curiosity, write a
| better rationale and hand it out on a pamphlet.
| bostonsre wrote:
| I think it's a solid concise article about the various
| rationales behind making technology decisions. A lot of the
| reasons given would make for a solid checklist to go through
| when trying to decide on a technology to use. A lot of the
| stuff he goes through is not obvious to people who have not
| contemplated these types of decisions before.
| Delk wrote:
| Sometimes people ask because they're curious. Sometimes when
| people ask that, the question really seems to be "I think
| people should use my favourite tech by default, so I expect you
| to explain why you've diverted from the Chosen Path". To
| exaggerate a little, but if you've met one of those people, you
| get the idea.
|
| I've seen both. The latter seems to sometimes occur with people
| who have a clear favourite (language|stack|whatever), mostly if
| they're also somehow overly confident that it's the right
| choice regardless of your problem.
| mdonahoe wrote:
| I suspect that's why he wrote the article. Now he can just
| point people to that.
| sergiomattei wrote:
| So rude.
| tytso wrote:
| Part of the whole point of this blog was to explain why it's
| not possible to explain and satisfy their curiosity, because
| the reasons can't be disclosed externally outside of the
| company (either because the reasons are under NDA, or involve
| lawyer's concerns over terms or conditions, or because the
| company doesn't want to call out some project leader as a toxic
| jerk).
|
| The blog post _is_ a general answer of why sometimes people 's
| curiosity can't be satisfied; pamphlets are so 18th century,
| after all. Sure, that's what the authors of the Federalist
| Papers used, but in the 21st century, we use blog posts instead
| of pamphlets. :-)
| jdougan wrote:
| Now I'm imagining the Federalist and Anti-Federalist papers
| restructured as a pair of blogs with links and comments. I
| like it.
| maerF0x0 wrote:
| That initial list is a brilliant checklist for before you stake a
| key part of our architecture on X, answer the following....
| reworded to the positive Does it perform well?
| Is it inexpensive? Is it open source? Does it
| lack features? Does it have a community? Does it
| have debug tools? Does it have maintainers? (or other
| quality symbols) It is properly documented? Does
| it receive timely security fixes? Does it show subject
| matter expertise? Are we the audience it was developed
| for? Why isn't our custom internal solution is good
| enough? Is it's longevity understood: Its startup may be
| dead or sold soon. Have we been in touch with the
| maintainer? Does this solution make sense for a
| reasonable window of time? Does it have industry
| credibility? Is the community Code of Conduct congruent
| with our values? Do our lawyers accept its T&Cs or
| license?
| [deleted]
| atoav wrote:
| As someone teaching electronics, media technology and programming
| at a art university I'd argue that the space between those who
| chose a solution because they didn't know it any better and those
| who considered every available option and made the rational
| choice is not only big, but the borders are foggy as well.
|
| At least with my students who are usually not experts at
| electronics, programming or similar things, the chosen solutions
| are often ridiculously naive. They would probably also work 90%
| of the time -- however they would (and do!) pay that naive
| approach by gaining an unreliable, expensive, overly complex rube
| goldberg type of system that falls appart when the stars don't
| align in just the right way.
|
| People like these are _extremely_ grateful when you sit down with
| them for a while, analyze their problem, explain some possible
| solutions to them and then in turn discover that there is a
| solution that is magnitudes less work, has magnitudes less moving
| parts and will probably also work in a decade. And you can do
| that without forcing your language or other strong preferences on
| them.
|
| There are many companies who chose the solutions they chose
| because they cannot imagine something else, they only have an
| employee who does x etc as well -- but assuming you can just
| recommend a thing and everything complicated about the problem
| would be neatly encapsulated and solved is naive as well.
| oriolid wrote:
| From the other side of the fence, more often than not when
| someone offers an open source or COTS replacement to an in-
| house system the result is that it replaces easily 90% of the
| functionality, but for the last 10% you need to either serious
| mental gymnastics to fit your system into the third party
| system's way of doing things or just put more effort into
| patching it than doing it from scratch would have needed.
| Sometimes the 10% is not really needed, sometimes it's the
| whole reason why the product was built.
| analog31 wrote:
| To be fair, this also happens if you switch to a commercial
| system, or from one commercial system to another. I can't
| count the number of times I've arrived at a health clinic,
| and was told: "Please bear with us, we just switched our
| system to **, and it has effectively shut us down."
| tpoacher wrote:
| worse:
|
| "why dont you _just_ use ... "
| cryptonector wrote:
| Another common reason is: it doesn't fit our culture. Or
| variations on that theme, like: we don't have people who could
| support it because we don't have people who understand the
| programming language X is written in.
|
| Obviously, the list of possible reasons (good, bad, whatever) is
| potentially very long. It's enough to consider a sufficiently
| large list of such reasons to understand why you might not be
| told a reason or reasons.
| bawolff wrote:
| > It tolerates brilliant jerks and has no effective CoC
|
| Is an interesting ones. Do big companies actually do enough due
| dilligence to know? I mean of course things can get to a point
| where the entire internet knows, but for most products i use, i
| have no idea what their internal culture is like and whether or
| not its full of assholes.
| Vanit wrote:
| Ah, the sibling of my favourite "why don't you jUsT X?" when
| describing a solution to someone.
| smileysteve wrote:
| For many of us though, ignorance and fear are blocking factors.
|
| A company used a postgres safe migration gem that blocked default
| values with a not null constraint that became safe 3 years
| earlier, but 1) nobody questioned with the tool version changes
| 2) once you learn a constraint it's hard to forget it.
|
| With the add that you have to take time to upgrade the gem if you
| want to keep using it.
___________________________________________________________________
(page generated 2022-03-21 23:00 UTC)