9 ms·
This post is so interesting to me, esp. the build-vs-buy spectrum. As Dan notes, a lot of software is just...not very good. It either isn't upfront with flaws
by mattgreenrocks 2y ago
This post is so interesting to me, esp. the build-vs-buy spectrum.
As Dan notes, a lot of software is just...not very good. It either isn't upfront with flaws (as in the case of the Postgres -> Snowflake tool), has too much scope, or is abstracted poorly. Finding things to buy/use (as in the case of open source) can often eat a lot more time than you anticipate.
I've been dipping my toes into the JS ecosystem, and I keep bumping into the fact that using mentally cheap signals of quality (such as stars or DL counts) almost never indicates the quality of the thing itself. Winners seem to be randomly chosen, almost! The only way to assess is to read the code and try integrating it in.
I'd go farther to argue that the larger an ecosystem/market is, the more untrustworthy it behaves as a whole, simply due to the size, and the types of people attracted to it who want to get influence/money. See also: appliances that everyone needs.
- onlyrealcuzzo 2y ago> Winners seem to be randomly chosen, almost! Winners are mostly chosen by effort put into marketing, not product quality.
- mattgreenrocks 2y agoHave definitely someone say, "well I tried Drizzle because the creators are good at shitposting on X." I do not understand that at all, but maybe my reality is just substantially less mediated by "the conversation" that I don't get it. (Drizzle is fine BTW)
- digging 2y agoI think that's actually not unusual or even wildly unreasonable shopping behavior in a market where: 1. Many if not most "customers" (JS devs) don't understand how to evaluate quality deeply (thus, quality signals aren't trustworthy, making evaluation more difficult and resulting in further acceptance of using unevaluated products) 2. There's an overwhelming number of choices, with deprecation, replacement, and eclipsing all being fairly common - potentially even year-to-year You kinda just have to try stuff out and work with what you've got.
- ZephyrBlu 2y agoWhat I translate that to is: "Drizzle is top of mind for me". If they tried Drizzle and it was shit, they would likely look for something else.
- thinkingtoilet 2y agoWinners are chosen because they tend to solve a problem easily for the average person. 99% of people don't care if it's written in rust or has the proper abstractions. It's, "I need to do X" and the winner does X easily. People here are very out of touch.
- nitwit005 2y agoIf no one hears about something, no one will use or buy it. It doesn't matter how well it does by any metric. Marketing will always matter.
- gmueckl 2y agoIt's a little worse than that. Given two products that seem to do the same job on paper, the one with glossier marketing will win even if it is an unreliable pile of crap in practice.
- axus 2y agoCounter-example: all the people that were using CentOS 6/7 instead of RHEL. Not that Red Hat did tons of marketing, but it was more than zero.
- deleted 2y ago[deleted]
- gmueckl 2y agoMy utterly cynical take is that the way to win with software is to put as much money and effort into marketing and sales as possible and as little as possible into the actual product. Especially B2B seems to do this a lot in practice because that software is bought based on checklist items and demos by salespeople.
- wussboy 2y agoI don't think this is a cynical take. I think it is the rational take. Anyone not doing this is going to be outcompeted by those who are.
- thechao 2y agoI also like that we try to build 'ratings' sites that end up being coopted as yet another ad sales vector.
- deleted 2y ago[deleted]
- onlyrealcuzzo 2y agoYou're starting to realize why eng is a cost center. The goal of the business it to make money, not make a great product. They will make the product better if and only if it will lead to greater profits. If you can make more money hiring more sales and marketing people to sell a broken product than hiring more engineers to fix the product, you're going to hire more sales and marketing people.
- closeparen 2y agoSo don’t work at a company that sells a software product to other businesses. Work at a company that has a business of its own, which runs more efficiently when the software is better.
- onlyrealcuzzo 2y agoYou're still in a cost center.
- changoplatanero 2y agosometimes having a higher quality product makes the marketing easier
- dayvid 2y agoCost as well. Most people don't want to invest in a high quality product unless it's something that is clearly miles above the competition (e.g. Vitamix, Herman Miller or Leap Chair, etc.)
- malfist 2y agoOr someone paid someone $5 and got thousands of stars
- wry_discontent 2y agoThe JS community has no sense of quality. The community doesn't value things that are well abstracted or work well. I dread every moment I have to work in JS because everything is so badly done.
- MichaelZuo 2y agoDo all the high quality folks just leave the JS community beyond a certain threshold?
- randall 2y agoOr start making their own stuff and ignoring most of the community.
- moron4hire 2y agoAfter a couple of years of doing this, you've built up a backlog of your own, bespoke library code that makes you into a wizard. People are amazed at what you can do and perplexed with how little time it takes you to do it. Nobody else can understand how it's built, but for some reason that's not their problem? It's not like they're taking the time to understand how React is built, either. But as soon as you do something on your own, whoooa buddy. Cowboy programmer alert. It's not good engineering if it's a single, coherent, vertically integrated system. It's only good engineering if it's a mishmash of half-solutions teetering on top of each other.
- golergka 2y agoSo you never work in teams with other people again?
- moron4hire 2y agoThis feels like a knee-jeek false dichotomy. But in a sense, it's kind of right. I didn't work in teams anymore. I manage them. I still do a lot of programming. And I expect my developers to be competent enough to read other people's code and figure out how it works, what it does, how to use it, based on the tests and plenty of extant examples. I don't want developers who can only be productive in libraries that everyone else's is using/posting YouTube tutorials on/feeding LLM training corpus'. The problem with adopting other people's software is that you have to make it work for your purposes, all while accepting it was only ever originally designed for their purposes. And if that's open source and you contribute to it, then you have to make sure all your changes don't break other people's work. But with my own libraries, I can break anything I want. I have, like, 5 projects using them. It's not a big deal to discover an architectural problem and completely refactor it away to a newer, better design, propagating the change to all the others that use it in fairly short order. And I don't have to argue with anyone about it. I can just do it and get the work done and prove it was the right thing to do long before any Github PR would ever get out of review.
- JansjoFromIkea 2y agoRE: stars and DL counts, I'd say the best measure is checking the creator's other repos, their number of followers and the issue churn rate. Stars can be useful but only as a very rough process of elimination. If the project appears to have several active contributors that would be good too.
- giantrobot 2y agoI'm a star inflater and I feel a little bad about it. AFAIK GitHub does not have a good "bookmark" mechanism besides stars. So when I come across an interesting/useful project I'll start it to be able to find it later. My browser bookmarks have become a bit of a black hole where URLs go to get lost. So hopefully I didn't bookmark a project someone else is trying to judge the quality of based on stars. Who knows how much technical debt or damage I've caused because GitHub doesn't have a bookmark feature that isn't gamified.
- Tknl 2y agoI've found the best way to evaluate the quality of npm libraries is to use Snyk analyzer https://snyk.io/advisor/check/npm https://snyk.io/advisor/check/npm
- tmountain 2y agoIt makes me really appreciate tools that DO work. Things like: the Linux kernel, Vim, PostgreSQL, the Golang compiler, etc. Interestingly, the aforementioned tools come from different ecosystems, and levels of financial backing, but all of them have been reliable tools for me for many years, all are complex, and yes... they all have bugs, but of acceptable severity and manageability.
- Roritharr 2y agoFor me the most interesting case is HeidiSQL. I find it easily the most useful SQL GUI client, but it crashes pretty frequently, but not frequently enough for me to stop using it over the alternatives. I often wondered how to strike the balance right on these things, since apparently all options can lead to success.
- touisteur 2y agoMight depend on the quality of crashes. Losing hours or days of work would quickly sour me. HP RGS crashes, twice or thrice daily are just 'meh' - reconnect and nothing - but 15 seconds and typing auth tokens - is lost - maybe 'flow' but I've become resilient there.
- teaearlgraycold 2y agoI have thought many times about building a shrine to Postgres in my apartment.
- lmm 2y agoAre you actually applying some objective standard for "works" here? Or are you just deciding that the bugs in things you like are "of acceptable severity and manageability" and the bugs in things you don't like aren't?
- tmountain 2y agoSure, using all the aforementioned tools for over a decade without any bugs that prevented me from completing a task.
- rvrs 2y ago>I've been dipping my toes into the JS ecosystem, and I keep bumping into the fact that using mentally cheap signals of quality (such as stars or DL counts) almost never indicates the quality of the thing itself. Winners seem to be randomly chosen, almost! The only way to assess is to read the code and try integrating it in. I wish morep people understood the "Kardashian effect" as I like to call it -- the most popular thing is only most popular because it was already popular. I think in almost everything in my life and in every domain, #2 or #3 is better-suited (for my preferences and needs). A year or two ago on HN I read a short blog post about omitting the word "best" from internet searches and being more specific in your criteria (e.g. "car with best resale value" instead of "best car"), and it has made my life and way of thinking a lot better
- chias 2y ago> I think in almost everything in my life and in every domain, #2 or #3 is better-suited (for my preferences and needs). Depending on the domain, there's a good chance #1 may also be a sponsored result.
- deleted 2y ago[deleted]
- Aurornis 2y ago> I think in almost everything in my life and in every domain, #2 or #3 is better-suited (for my preferences and needs). I like to explore alternatives to the most popular choice, but more often than not I end up back at the #1 consensus choice. I have some friends who simply must pick the #2 or #3 choice in every domain. They always have an elaborate justification for why it’s better. From my point of view it seems driven by contrarianism. Some times they pick some interesting alternatives that I explore. Most of the time they end up with also-ran purchases that die off. I joke that my one friend is the best predictor of impending product line cancellation that I know. He used a Zune when everyone went iPod. He went Windows Phone when iPhone and Android were front runners. He event eschewed Instagram for some other platform that he was sure was going to win the social media wars, but was actually so unnoteworthy that I can’t even remember the name right now.
- saltminer 2y agoI've seen this same problem with many so-called low-code/no-code application creation tools (e.g. Betty Blocks). In their quest to cover every use case, they cover none of them well, forcing compromises and creating more real-code work for the actual application developers whose systems have to be accessed by these tools. It would have been quicker and cheaper if the company just hired more actual developers to integrate properly with existing systems (and resulted in more featureful, less buggy applications), but the prospect of paying lower salaries for less qualified people to do the same end result (as promised by the slopware vendors) seems to be a siren song of sorts to management.
- ycombinatrix 2y agoLow code platforms are highly effective solution to part a fool from their money
- nradov 2y agoYou're missing the point of low-code/no-code solutions. Those are intended to sold to executives who don't actually understand software, as proven by a prior history of buying other crap software. Whether it actually works or saves any money is irrelevant.
- jd3 2y agoMany of the best engineers that I have worked with over the years have a discerning constitution which seems to innately allow them to identify high quality software, which is essentially a matter of taste. The problem is that this disposition is not the norm for a technician, which is why I tend to prefer hiring and training engineers that are artistic, creative, and obsessive.
- Aurornis 2y agoI once thought the same thing. Over time I realized those engineers weren’t necessarily good at picking the right thing up front. They were good at making it work despite any deficiencies.
- ozim 2y agoI would argue that our whole civilization works because people either accept deficiencies or make up for the deficiencies on their own.
- randysalami 2y agoKeep on fighting the good fight
- mattgreenrocks 2y agoSoftware will continue to be garbage until we expect more out of it. And that extends to the people writing it. This isn't a profession that is kind to people who want to do things by the book. We incinerate the book every few years, but the fundamentals remain the same.
- blueyes 2y agoFor me, what this post illustrates most is the cost of information. By making hasty decisions, buyers are trading present time that might be spent shopping and comparing with future time spent struggling with the wrong product. They're discounting future time. But they're also doing something very rational -- they're making a decision to see what happens. That is, they're testing a hypothesis in the only way the market allows them to. Because people are bad at predicting their own future needs and behavior, and products are bundles of features whose importance is often unknown until you have to use them in high-dimensional futures. So buying is an empirical test. Unfortunately, most consumers, recruiters and sometimes hiring managers are in a position of information assymetry vis a vis the people selling them something. That is, consumers rely on the self-reporting of vendors which purport to be experts. https://vonnik.substack.com/p/the-expert-layman-problem https://vonnik.substack.com/p/the-expert-layman-problem
- soco 2y agoTheory (and practice too) says that whatever was used in the proof-of-concept also stays. I mean you are right the initial thinking is to try and evaluate the fitness, but then you're already invested and unless the fitness is abysmal (it rarely is) everything else will be rounded and squared to fit the already implemented hole...
- benreesman 2y agoYou’re giving pmarca too much credit: he’s just lying. Ya know, for personal profit. Starving for talent my ass. His portfolio companies have infinite appetite for talent at zero cost, the minute one person wants one point of the upside they’re right back to starving for free talent. Silicon Valley is the ultimate thought experiment in how wealth inequality plays out when resources are effectively inexhaustible. You don’t have to speculate about a post-scarcity world, this is a post-scarcity world. Ballers in SV ship a billion in revenue on a Tuesday. And yet somehow it’s Andreessen who ends up with all the chips at the end of the night. These talking heads don’t have a plan, they don’t know what their next big payday will be, they don’t code, they don’t design, they don’t sell anything other than their own personal brand, they don’t add value. They’re just patient and connected like zen spiders sitting on a web: they’ll learn first about a new big thing, they’ll be there immediately, their friends will wire up the deal in their favor, and they’ll do a TED talk a few years later about how making themselves absurdly wealthy with no real effort is somehow the future of humanity. They openly advertise their glee at the (ridiculous) idea that soon some autoregressive language model will do all the work and the owners of NIDIA cards can just pocket it all. In the 90s there was this meme of a yuppy couple doing a business from their couch via “The Information Superhighway”: outsource everything, all you need is a laptop, a glass of Chardonnay, and a lot of cheek. pmarca should spend less time yakking about AI on Lex stream and more time learning AI on geohotz stream.
- deleted 2y ago[deleted]
- ChrisMarshallNY 2y agoI never even look at stars. I hardly have any on my work, and that's fine with me. My stuff is of extremely high Quality, because I use it, myself. I'd actually prefer as few others as possible, use it, because then I'm Responsible to ensure that it works for them, and I can't just go in and do whatever I want. I also use almost no software that has been written by others. I use two or three external dependencies, in my work. Two PHP ones, and one Swift one. All are ones that I could write, myself, if they got hit by a bus, but they do a great job on it, and, as long as they remain bus-free, I'm happy to use their stuff. The one exception is an app that I just released, using SwiftUI. I needed an admin tool that displays simple bar charts of app usage data. I was going to write my own UIKit bar chart widget, but SwiftUI has a fairly effective library, so I figured I'd use it, and see how SwiftUI is doing, irt shipping apps. I think that I'll avoid using SwiftUI for a while longer. It's still not ready, but it has come a long way, since my first abortive attempts at using it. The app works, but I did some customization, like pinch-to-zoom, and that's where SwiftUI kicks you in the 'nads. As long as you stay in your lane, things are sick easy, but start driving on the shoulder, and you are in for some misery. And that's the biggest problem with relying on someone else's code. They usually punish you for any "off-label" use. Apple has always been like that, but they usually let you get away with it. I go "off-label" all the time, because I don't want my apps to look like Apple Settings App panels. SwiftUI doesn't suffer deviance at all. Just adding pinch-to-zoom was a bit of a misery (but I got it going, after several days of banging my head, and it now works fine). Some frameworks and libraries won't let you deviate at all. You can't have any pudding, if you don't eat yer meat.
- silisili 2y agoI'm finding similar results. I used to just write everything myself when a need arose, but in trying to better spend my time I find myself checking what's out there. And inevitably I'll find something that will claim to do exactly what I need. From there, I find two problems rather often. One, it doesn't actually do what it claims. Googling is fruitless because I must have been the first one to actually try it. Gotta love Googling an error and finding exactly one result - the source code. I sometimes open a bug report depending on how the project seems, and that gets anything from deaf ears to "oh thanks, we'll fix it in the April release" which is of little use to me now. The other is something you touched on briefly, that the API or contract changes in unexpected ways over time. You can stave this off for a little while by pinning, but then you're missing out on bug fixes and new features. Which, especially for a middleware type thing, is usually a death sentence by bitrot.
- CharlieDigital 2y ago> I keep bumping into the fact that using mentally cheap signals of quality (such as stars or DL counts) almost never indicates the quality of the thing itself. I find that docs are typically a really good proxy for quality. Solid docs with clear expression of intent (design, usage, features) is usually a good sign. Astro.js, VueUse, Quasar (it's ugly, but amazing).
- arcanemachiner 2y agoI've never used it, but I'm surprised to never hear anything bad about Quasar. It seems like a pretty niche project with am enthusiastic following. Like Elm, but even more niche.
- CharlieDigital 2y agoThe components are the most complete set I've come across and cover a really broad famit of use cases. Docs are really good. Great toolset for building fast (though AI now may bias towards Tailwind and just generate whatever you need).
- benreesman 2y agoBasically everything Dan posts online is deeply insightful, fearlessly honest, thoroughly footnoted, and dryly humorous. I think even he is a little averse to straight up saying it out loud (we’ve discussed it many times): software and product outcomes have gone to shit because we don’t enforce anti-trust law already on the books, let alone update it in light of 50 Moore doublings. You want a smart phone? Here are two vendors with the same App Store vig at payday loan shark rates. You want to rent cloud compute? Here are several vendors where the 4th place vendor charges the same as the first place vendor. You build disruptive encrypted messaging app? You better live on a boat and watch your six like Jason Bourne Mr. Marlinspike. Is it even a little surprising that everything from Google search to Netflix is a shittier version of itself ten years ago? There’s no incentive to make it compelling!
- 0xDEAFBEAD 2y ago>I think even he is a little averse to straight up saying it out loud (we’ve discussed it many times): software and product outcomes have gone to shit because we don’t enforce anti-trust law already on the books, let alone update it in light of 50 Moore doublings. None of the examples of crappy software from the OP are Magnificent 7 companies, are they? Those companies seem to be capable of hiring the best talent. A critical input into the build vs buy decision is whether your company is actually capable of building. Suppose Dan was advising the company that made the crappy Postgres/Snowflake sync software on whether to build vs buy a supporting component. Given that their main product is already crap, can they really be expected to build a better supporting component in-house? Seems like they might as well buy, and focus their energy on fixing the main product. Dan advocates vertical integration here, and elsewhere says engineers get better compensation from FAANG than startups. This suggests that big companies made up of lots of talented engineers have natural efficiencies, relative to the alternatives. A natural interpretation of "antitrust" is: break companies up into their smaller business units. That basically replaces an in-house "build" relationship with an inter-business "buy" relationship. So it seems antithetical to the OP. Dan, if you're reading this, I encourage you to write a reply here on HN tearing me apart, like you did to all the other HN commenters.
- 2y ago
- insane_dreamer 2y agoThe reason why software is crappy compared to physical products is because products come with a warranty and software doesn't. If you buy a blender and it makes some strange noise, you don't think twice about returning it, and maybe buying a different brand. If it breaks later, you can get repaired for free under the warranty, or else get it repaired. You have none of these recourses with software. Yes, there are trial periods but that's not the same as buying and returning, and they're usually shorter than return windows. And there's never any guarantee that it will "just work". We have managed to convince consumers to put up with software that "breaks" in a way that they would never do with hardware.
- PeeMcGee 2y agoAlso there's no ceiling to the debt that can accrue from integrating a certain software with a product, and when that debt stalls for a while then it'll just become accepted as part of the process. Whereas a blender has a debt ceiling of 1 blender, and the labor time of maintenance boils down to placing an order for a new one occasionally.