Why Don't You Use
brendangregg.com
brendangregg.com
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.
The question of that form is akin to “proving a negative”
Personally, I always get that feeling of fright plus eagerness. "Oh god, have we wasted our time" plus "Oh man, can we save so much more?". And you only have to explain to coworkers once anyway. They'll either demonstrate their idea is better or turn into additional broadcasters for the viewpoint.
I think the premise of the article is dealing more with random drive-by comments where the person is really just advertising x, rather than being genuinely curious.
Now, admittedly, it's very tone dependent. "Why don't you X" can be asked humbly and with a truly inquisitive tone, or with a sneering tone whose obvious implication is that you must be either ignorant of X or too dumb to see its merits. But in writing, at least, I try to infer the more charitable attitude of genuine curiosity.
But yes, I also try to interpret it charitably as well too. I just also try to make my own curiosity clear on the flip side.
There's a whole thing called nonviolent communication and the basic premise is that if you spin someone up by choosing your words poorly, that's as much on you as it is on them.
That said, sometimes even the most skilled communicator might find themselves spining someone up despite their best efforts. At the end of the day all we have is self awareness and good intent, but if the other person is hell bent on being oppositional, that's gonna be very hard to navigate.
Also, if you want to understand why someone did Y, ask deeper questions around why they did Y, don't ask why they didn't pick the other 500,000 possible solutions.
Often I've asked it because I privately thought "why didn't they use X?", but I'm seldom actually interested in hearing why they didn't.
Firstly, and sadly, I get a bit mentally stuck on X. Secondly I assume I have missed something. Whatever I have missed is probably quite important, since otherwise X was a good choice.
Both of these effects mean that I will probably learn a lot from knowing why someone decided not to do X. So, if I've been mulling the question for a while, and can't get an answer, I think it makes perfect sense to ask "why didn't you do X". After all, that is exactly what I am wondering in good faith.
It sucks that the question is often used sarcastically, because to me it's a very useful question for understanding someone else's process.
But ROS is indeed a popular framework for robotics, so the question is a reasonable one to ask.
I've also say through Q&A sessions where a guy got up to the microphone to recommend books for the guy giving the presentation to read. It was uncomfortable.
Because even if you exclude the concern trolls who aren't actually interested in your answer, just fighting with you, it is a never-ending stream of people who want to bikeshed your choices devoid of the context that makes it worth even trying to answer.
Life is too short.
As the running joke on the TV series goes "Phrasing". Phrasing is the key difference, especially in a textual medium. As you point out, it's the tone.
I've seen "Why don't you do X" phrased in a variety of ways, and the best phrasing I've found seen was along the lines of "I would normally do X in the scenario you've described, but Y was obviously better for your use case, would you mind sharing why?"
The worst possible phrasing of "Why don't you do X" is "Why would you even consider Y, everyone competent knows X is how you do it".
...and then it turns out that actually, Y was the best way to approach the given use case, X wasn't suitable, and now someone looks like a bit of a dick.
There are multiple assumptions in that question that could make it crash and burn really badly. What if they actually didn't consider X? What if they do think Y is better, and X is interim? What if they had a lazy reason to prefer Y, and interpret the hyping up of the quality of their decision as calling them out?
As opposed to assuming they're cousin loving inbreds who did Y because they hate every computer scientist ever.
Assuming that doing Y was indeed wrong, and you want to correct that... do you think approaching it with the mindset of "you're a competent person who made the best choice you could see" is going to work better or worse than approaching out as "you're so incompetent, I've met more capable toasters, and you obviously did this because you hate America"?
It's just people skills, my friend. Start your disagreements by assuming the best of your opponent.
And why is this an "opponent"?
How about both not being rude and trying to minimize assumptions?
Consider that they probably looked at X, but don't put them into an extremely awkward position if they didn't. And the same for the other things I pointed out.
It's just people skills, my friend.
That being said, I love being challenged. Also by people new or un experienced in my field. Because it's an opportunity to learn. Either because I missed something (naive questions are really great for that), because I have to voice my thoughts and explain my thought process (and discover flaws in it), because the person asking is way better in what ever we are talking about,... you name it. Being challenged just because definitely isn't part of that.
What tone do you want?
I'm extremely confused, and I don't understand your implication that an inquisitive tone won't be respectful or polite.
(And when it is curiosity, it's less offensive from someone that doesn't know much, which is part of what threw me off so badly.)
However it's a great question to understand why certain decisions were made. The best engineers know that most of the work gets done in the planning and decision-making, not by stubbornly diving into something. If it was really the best decision at the time then the merits should stand the test, otherwise the defensiveness to answer is far more suspect than an innocent question.
Asking why you did something is a reasonable question. Asking why you did not do something tends know-it-all and/or help-vampire territory.
Instead of assuming the asker is a "know-it-all", what if they actually do know more? I've learned more from counter arguments (both hearing and making them) in all aspects of engineering and life in general.
I'll never turn down such a question and actively engage them because it makes me aware of alternatives at the very least, and often helps in future decisions. There are plenty of stories posted on HN of poor decisions that probably could've been avoided if someone considered some alternatives.
"Why don't you use Reaper?"
"Why not Bitwig?"
"Why not Linux?"
"Why not Ardour?"
"Why not LMMS?"
(the answer is "I spent tens to thousands of hours in each and they all feel like a regression next to Ableton Live and my very stable and productive Windows 11 Pro install")
This is music, but from this thread it sounds like it's the case with most fields. It's always the Standard Alternative Suggestions that assume the askee is an absolute novice who wouldn't be aware of and wouldn't have extensive experience trying or at least considering the entire space of possibilities before settling on a path.
"Why do you assume the asker is a know-it-all?"
Experience. It's cool that you have a different experience where it's not a waste of time.
This lead to the pathological condition whereby adding engineers to the team slowed progress, as it simply created more values for x.
If you piss off enough people over the course of a 6 month to a year project, it's unlikely that the perception of even a game changing win will be positive. As most large companies base promotions off of feedback, pissing off the wrong people will also block development.
When you see tenured members of a team exhibiting certain behaviors, it's often due to those behaviors optimally solving for the incentives of the organization.
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.)
I use x. Y exists. When someone pitches y to me, I'm happy to stipulate that y is better. (it is, or isn't, but that doesn't matter, so I'm happy to concede/ignore that point.)
The question is, will Y compile all my existing code? Since the answer to that is no you are suggesting either
A) we rewrite existing code in Y. Or B) we add resources enough to build new stuff in y while maintaining the existing in x.
That becomes an economic question not a technical one. Also what happens when all my highly qualified, experienced, and proficient X leave (cause their careers just came to a dead end) and in left with the thing we actually sell and no one to support it?
Swapping y for x sounds like a technical decision, but is far more an economic /existential decision for some part of the business [1].
[1] I'm not talking about the small stuff here - we can easily swap out a text editor, but changing a language or in some cases a database is a big deal.
As an example from my experience, when Apache Spark became popular (around v1.8), there were a fair few people in certain circles sneering at Hive, clearly Spark was superior because you could cache intermediate results to RAM.
Except Spark at the time (I haven't used it in anger since v2.2) was rather terrible at the very large datasets Hive could grind through with no issue. Sure, Hive was slower, but then it had the distinct advantage on very large datasets of not dying with an OOM error 2 hours into a job.
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.
But that can be a downside for finding stuff. If everything is in one spot, each time you're looking for something you may have to look through everything. If everything is split up over X spots, you usually only have to look through 1 / X amount of stuff in the spot you're searching.
Used to be; not so much any more.
This is related to the "directories vs tags" discussion, and that whole "the kids don't even know what files are any more" thing.
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.
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?IMO If you're really staking a key part of your architecture, you should be comfortable enough with the technology to basically be able to document/maintain it yourself if you need to.
Put another, if your understanding of the tool/stack depends on someone else making it accessible to you, either you have an unshakable trust in that someone else, or you're in for a wild ride. I'll concur sometimes you might not have a choice.
For me, lack of proper documentation constitutes a red flag, and says something very negative about the project. The question "Is it properly documented?" serves as a simple and convenient way to filter out projects that have a low chance of being mature enough to fit my needs.
I hear you, my point is there are dozens of other convenient questions you can ask to filter out projects.
For me personally "Is it widely used in production" is a better one for instance.
Absolutely. And I agree with you that "Is it widely used in production?" is a better filter. But that does not diminish the value of the filtering done by "Is it properly documented?". After all, it's not like we're limited in the number of criteria we can use to filter out bad projects.
Hmm. Not entirely sure I agree. To use an example, I find it much easier to read https://pkg.go.dev/encoding/json than the dozen or so files in https://github.com/golang/go/tree/master/src/encoding/json
Perhaps I'm misunderstanding your point.
If you are on the completely blind side, documentation is your only window into how it works, and good documentation is non negotiable (you will take a slightly worse working library if it has way better documentation).
In comparison if you adopt a library as a time saving move, and audit all of its code the same you would review your own code, good documentation is a nice to have, but won't be the make or break point of your decision. You'll chose the better working code even if its documentation is meh.
I you are putting your fate into a specific stack or library, I hope it falls on the latter category than the former. On the two json libraries, I guess they both work decently, and the only criteria is which one feels better to use ?
- 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!
The OP framing can be helpful when the manager has context on solution X and its pros and cons so it’s helpful for the team to explain through a shared understanding.
it doesn't solve a problem that we have.
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)
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.
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.
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.
That reason exists only in the wet dreams of a few open source social justice troublemakers. No corporation would refuse a great tool that fits their use case over what happens in its mailing list or whatever.
It's hard to get brilliant jerks to accept new ideas. It's hard to motivate your engineers to invest deeply in toxic, unfriendly ecosystems. Of course, extreme technical success can outweigh many of these factors, but that's the exception and not the rule.
Someone who can work with toxic and unfriendly upstream anyway has an advantage; they are able to get stuff into a project that is stable because it loudly rejects crap and fluff.
A corporation doesn't care about toxic and unfriendly; that just describes their world, pretty much.
If I'm dealing with some external project as part of company work, that's the situation in which I least care about people's personalities. I represent a company, not some individual and his fragile ego. I might be in charge of upstreaming something that doesn't even have my own name on it.
In business you have cutthroat competitors who unfairly bad-mouth your product.
You have irate, rude customers.
You may have suppliers to whom you are a low priority because their volume is elsewhere.
Your HR doesn't control any of those external people. You have to be cool as a cucumber, or it behooves you to be so.
I've pushed back on "why not X?" before; the most often reason being "it does not have the features we need". Then implemented it anyways when some astronaut architect decreed it shall be so, and duct taped around the aforementioned gaps as best I could. To whomever handles that in the future: I'm sorry.
Or sometimes the decree just comes down "adopt X" with nobody really having done any legwork to see how good X actually is in practice and we just find out by adopting.
> Why not protocol buffers?
Because we were looking for performance, but the backend was in Python and wasn't getting re-written in Rust anytime soon, and JSON was faster because it is a native C extension¹.
¹and technically, protobufs can be too. We evaluated the C extension, and there was one problem with it: it reliably segfaulted. We disabled it, and tried the pure-Python version, but it lost to JSON.
> Why not cloud-managed relational DB?
We need spatial indexes, and the cloud provider didn't offer them, then later did offer them but they didn't work. I hear they work now, but we didn't wait around for the cloud to implement…
Although sometimes, the answer is just "honestly, I'd love to adopt X. Haven't had the resources to do it, (probably, haven't had the time)."
- 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
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.
Because the computer we would run it on is not connected to the internet.
From google docs to numerous npm-things, there's myriad software I was unable to run at a digital forensics shop.
And of course the opposite is true: we were always thankful for software who's authors had taken the time to make work offline.
This also happens in companies. Unfortunately, in tech you're penalized for not speaking up in meetings, and the easiest contribution to make is often "why not X?". Sad but true.
> Phrase not found
Aw, come on.
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.
"why dont you just use ..."
(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.)
Most of our customers are reasonable rational people who use MongoDB alongside a collection of other database technologies.
Personally as someone who has worked in pre-sales and more recently developer relations, at MongoDB I find our customers and users are suspicious of zealots.
Are. "Art" goes with second person singular ("thou"), not plurals.
Also, it looks like you're using "wherefore" as a synonym for "where". It isn't; it means "why". (Compare Ger wofür, Sw varför, etc.)
This meme is from 2010, the dust has settled. But there are plenty of tools generating the same kind of zealotry these days. It used to be "why don't you use MongoDB ?", now it's "why don't you rewrite [X] in Rust ?". Call them early adopters instead of zealots if you want. Some of these early adopters just act like they've discovered sliced bread and obviously others are fools for not using it. And later the dust settles.
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.
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.
If you are looking in there and keep seeing someone who is very often right but also very condescending about it, you can tell they tolerate brilliant jerks.
I've worked with a lot of brilliant jerks in my life so it doesn't bother me, but it bothers a lot of other people, so I still try to avoid it.
This is a good perspective. There's a gradient of intersections of levels of Brilliant and Jerk, and everyone has a cutoff point for Jerk where Brilliant stops being worth it. If you optimize for Brilliant and try to limit Jerk, it's probably easier to referee between a Jerk and someone with a different tolerance when they have to work together since there's less distance between tolerance levels.
I was talking to a company about a role, and one of their ex-employees warned me that one reason they'd left was that the company required contact with shitty upstream communities that make contributors' lives very unpleasant. I passed on that role, and one item I carried from the experience was that in discussions about a subsequent employer's open source contribution was that we needed to make sure that we weren't expecting people to deal with upstreams whose behaviour would be drive our staff out, or give them grounds for legal action against us.
So yes.
Have you been tempted by any other frameworks etc ?
This is open-ended on the side if the person being asked wants to demonstrate additional knowledge. At the same time, it invites the simple response: We have, but [our approach] seems best for us now.
That's pretty arrogant. In fact, big companies have many (influential) people who've been working there for a long time and have relatively weak knowledge of the technology landscape outside their company.
Tell me how it will solve my current (not future) challenge without making any subjective assumptions but knowing what we are trying to do, and better than the technology/* we have chosen ourselves.
Then usually people shut up.
There's a lot of decent tech not used by companies because some guy didn't like the project.
That's what she said.
* The benefit X will bring in the foreseeable future does not out weight the cost of switching.
* We have limited engineering resources and they're better spent working on Y.
If you’re tired of explaining to satisfy their curiosity, write a better rationale and hand it out on a pamphlet.
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. :-)
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.