13 ms·

Why Don't You Use

• buescher 5y ago
  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
• kazinator 5y ago
  > It tolerates brilliant jerks and has no effective CoC. 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.
  • umvi 5y ago
    Right, can you imagine telling the higher ups "Sorry, we can't use Linux like our competitors because Linus Torvalds is a brilliant jerk and he swears at contributors sometimes which is harmful to inclusivity"? Yeah right. Most FOSS users don't say boo to the maintainers of the software they are using, let alone contribute.
    • akshayshah 5y ago
      But many large companies, like Brendan's, _do_ contribute to large projects that they use. To successfully adopt big pieces of OSS infrastructure, large companies often want some assurance that their bug fixes, performance improvements, and possibly feature additions can be upstreamed without too much pain. 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.
      • kazinator 5y ago
        What any sensible company wants is that their changes get upstreamed, but changes that they don't care about from other sources (such as other such companies) do not. 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.
• sergiomattei 5y ago
  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.
  • mdonahoe 5y ago
    I suspect that’s why he wrote the article. Now he can just point people to that.
    • sergiomattei 5y ago
  • tytso 5y ago
    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 5y ago
      Now I'm imagining the Federalist and Anti-Federalist papers restructured as a pair of blogs with links and comments. I like it.
  • bostonsre 5y ago
    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.
• AdmiralAsshat 5y ago
  Ctrl+F: legacy > Phrase not found Aw, come on.
• loudmax 5y ago
  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 5y ago
    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.
• swatcoder 5y ago
  > 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.
  • RealityVoid 5y ago
    But, sometimes, a lot of times... It's just "the way we do things here". Some companies really are insulated from outside inovation.
    • alar44 5y ago
      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 5y ago
        That feels like you dodged a bullet based on how I experience using Teams vs Slack.
• thrashh 5y ago
  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.
• a_c 5y ago
  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 5y ago
    This is how we had people using CVS in 2010 and Subversion in 2020, and why we can never get rid of autoconf.
• bitwize 5y ago
  (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 5y ago
    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.
    • JodieBenitez 5y ago
      It's not really about MongoDB which may or may not be a good fit for your app (personally I was never faced with a good use case, but that doesn't mean it's not any good elsewhere). It's about MongoDB zealots and more generally about people following the trend instead of making proper choices based on their real needs.
      • gqewogpdqa 5y ago
        Lol. I heartily endorse people making proper choices based on their needs. With the proliferation of shiny things for developers, it's really important for people to have this focus. Very good point.
      • jd_mongodb 5y ago
        MongoDB Zealots I hear you say? Wherefore art these zealots? I watch social media for MongoDB on a regular basis and I can't say I have come across much zealotry in the last 8 years :-) 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.
• atoav 5y ago
  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 5y ago
    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 5y ago
      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."
• ape4 5y ago
  I don't want to rewrite my app when the framework/API inevitably changes.
• deleted 5y ago
  [deleted]
• deleted 5y ago
  [deleted]
• cryptonector 5y ago
  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.
• em-bee 5y ago
  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)
• tpoacher 5y ago
  worse: "why dont you just use ..."
• smileysteve 5y ago
  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.
• dasil003 5y ago
  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.
  • gkop 5y ago
    Infuriating indeed. It’s not just internet randos though, it’s also (for example) engineering executives lacking in self awareness.
    • tapas73 5y ago
      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 5y ago
    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.
  • tchalla 5y ago
    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”
    • hutzlibu 5y ago
• maerF0x0 5y ago
  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 5y ago
    [deleted]
  • makeitdouble 5y ago
    > It is properly documented? 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.
    • blindluke 5y ago
      You're assuming someone places value on proper documentation because they need proper documentation to make it "accessible to you". That doesn't have to be the case. 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.
      • 5y ago
• bawolff 5y ago
  > 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.
  • k__ 5y ago
    Sometimes the jerks are too brilliant...
  • jedberg 5y ago
    Usually when evaluating a new technology, one of the important things to do is look at the public support channels and see the kinds of problems people are having and the solutions. 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.
    • Kye 5y ago
      >> "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.
  • rodgerd 5y ago
    > Do big companies actually do enough due dilligence to know? 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.
• lliamander 5y ago
  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.)
  • random314 5y ago
    +10
  • Thorentis 5y ago
    Yeah, I suspect the most common reason is some version of "we have already spent millions on hiring people with experience in x, and it would be too expensive to refactor and use y". Sometimes the best tool is the one you already own and use.
    • bruce511 5y ago
      A million times this. 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.
• gonehome 5y ago
  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.
• jmtulloss 5y ago
  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 5y ago
    Personally, a better framed question which works for me is - “What options did you consider and how did you choose this option?”
    • jmtulloss 5y ago
      Agreed, there are lots of ways to explore the problem space. 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.
• Vanit 5y ago
  Ah, the sibling of my favourite "why don't you jUsT X?" when describing a solution to someone.
  • Underphil 5y ago
    Maybe so, but we don't want to completely stifle the curiosity of new or junior staff. There's a time and a place though.
• HeyLaughingBoy 5y ago
  > 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.
• hiisukun 5y ago
  Another straight-forward but non-obvious reason, depending on your industry: 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.
• httpz 5y ago
  For startups the reasons are more often: * 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.
• irrational 5y ago
  One thing I’ve noticed is that people who haven’t worked for large companies think that if you work for a huge company that money must never be an issue. That’s not true at all. Everyone works for a department within the organization. Your department has a fixed budget. It’s basically like working for a tiny company within a larger company. Just because the large company made X billion dollars in profit last year doesn’t mean that any of us peons have access to that profit beyond our allotted budget.
• Lamad123 5y ago
  Or maybe your codebase is just crap and changing something would require tearing the whole thing down!! It happens more often than it doesn't even in great companies!!!
• da39a3ee 5y ago
  > It's rarely because we don't know about it or don't understand it 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.
• deathanatos 5y ago
  This. 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)."
• noduerme 5y ago
  Even more annoying is the question "Why do you still use..."
• deleted 5y ago
  [deleted]
• danielovichdk 5y ago
  I usually ask this if someone asks me "why don't you use" - 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.
• jokethrowaway 5y ago
  True, but the analysis done in companies have variable quality and are subjected to bias / preferences of whoever is tasked with doing the research. There's a lot of decent tech not used by companies because some guy didn't like the project.
• marcAKAmarc 5y ago
  "It tolerates brilliant jerks and has no effective CoC." That's what she said.
• phendrenad2 5y ago
  The worst part is 99% of the time the person asking "why don't you use X?" has never used X, and 90% of the time doesn't even understand X, and 50% of the time has merely seen "why don't you use X?" used for this particular situation before, and is trying to score internet karma points / upvotes by being the first to ask it. 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.
• a9h74j 5y ago
  Could this be a less offensive question: 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.