I learned that the hard way, that I am at a place where people are on the left side of the bell curve and that you shouldn't be developing your own stuff with such a team.
Cost me some credit. Now I am trying to get us away from the awful mess we produced.
You can build excel by relying only on standard ISO/ANSI C features. The fact that they felt like they were better than using a fully standard compliant compiler says more about their lack of competence than anything else.
You could learn to properly use ANSI C, or you could write your own compiler instead for some subset of C and pretend like youre smart for it.
It would make sense why MSVC has pretty much no C support, and why so many MS products are so uniquely bad, instead of being bad in the same ways (uniformly)
> You can build excel by relying only on standard ISO/ANSI C features. The fact that they felt like they were better than using a fully standard compliant compiler says more about their lack of competence than anything else.
One of the worst things about the modern internet is people can be so rude and disrespectful to people they've never met for decisions they know nothing about. The custom compiler was used in the 80s and early 90s for P-Code and was a way of dealing with the perceived proliferation of multiple CPU architectures, as well as producing significantly more dense code. This mattered a lot back then.
Excel didn't really have its own C-compiler. Microsoft at that time had two (and a half) groups, Systems which included MS-DOS (and "languages"), and Applications who were developing "office" applications. The apps group had its own compiler known as "cs" and organized around interpreted p-code which is smaller. This compiler was written for Multiplan and Word before Excel was even conceived.
MS-DOS was written in assembly, and very stripped down and small, but office apps needed to be somewhat fatter with luxurious features so memory was an issue. Microsoft was working on a C compiler but wasn't selling it as a product (although, did they license Lattice C for awhile?) Ultimately, the cs compiler was added to Microsoft's C compiler as a p-code option. Ultimately ultimately people stopped caring about small memory and the utility of pcode went away.
I was already answering "it depends" on three of them.
> 1. Code Reuse is:
"Code reuse" sounds good, but if you abuse DRY ("Don't Repeat Yourself") then you can easily get into a mess that would have been more maintainable if it had been separate structs/classes/functions/modules in the first place, even if there's some duplicate code.
My rule of thumb is, if the purposes are different, then they should be separate things, even if the code is exactly the same line-for-line. When (if) it becomes obvious that we're always updating the code on multiple sides, then we can start considering combining them into only one thing.
It more or less aligns with the Rule of Three.
> 2. Reinventing the Wheel is:
It sounds "bad" because there's apparently "duplicate effort that you could have saved if you just used this library", but you have to remember that now you're at the mercy of this library, and unless you're paying for it, the maintainers can do whatever they want with it, including removing it or even using the name for a different thing (e.g. "tree-analyzer" being initially something related to ASTs (Abstract Syntax Trees), but then being re-purposed as an OpenCV tool to identify tree species (plants) from pictures).
And also following the wheel analogy, we can't forget that reinventing the wheel was necessary because modern cars can't use wheels destined for horse carriages; and airplanes can't use wheels used by cars. It wasn't just a matter of making an existing wheel thicker, or just using a different material; the whole build process is different.
> 3. The Not-Invented-Here Syndrome is:
The article sums this up nicely: "If it’s a core business function — do it yourself, no matter what."
He was bucking the prevailing wisdom a bit. We had gone from cowboy coder teams building everything themselves, to highly structured/abstract code bases. "Don't build if you can buy, don't roll your own if there's an existing tool, if you do build a tool, make sure you make it in a way that's reusable." Etc.
Here, Joel was saying that there are exceptions to the rule. That better teams should consider these exceptions before just leaning on the conventional wisdom.
I think in the decades since this article was first written, his way of thinking has become more common.
The caveat here is in the "if your team is competent", and, as much as I love some of the people I worked with, their code can be downright horrible. Sure, they write good code in language ABC, but not in language CDE, but insist that they do. Or maybe they write great code, but no documentation. Maybe they even write good code, and a lot of it, and then leave. And suddenly, you have to not only find someone who
- can read the code, and
- is good at this technology, and
- has the domain specific knowledge to work on it,
but also someone who will be part of your team.
Further, NIH only works out well when youre not under strong pressure. Someone tells you to build XYZ, and you have NIH syndrome and build dependencies yourself, you will do so under a lot of time pressure, and it will be shit no matter how good you are.
> Someone tells you to build XYZ, and you have NIH syndrome and build dependencies yourself, you will do so under a lot of time pressure, and it will be shit no matter how good you are.
It can go both ways though. You have the opposite of NIH, and say "there's no way in hell I have time to build this", so you pull in some huge unwieldy library that mostly solves the problem, and end up spending more time jamming a circle into a square hole and plugging up the gaps than you would have spent just solving the problem.
Yeah. Usually the cost of adding a dependency is over the long-run, so it disappears in the near-term decision making, but sometimes it's so significant it shows up in the near-term. It's good to notice when that's going to be the case and point it out to those applying the pressure, because that will be in a language they'll hopefully understand
You see that a lot with some enterprise software. They get you started quickly but then you spend enormous amounts of time and energy customizing it to achieve the last few percent of functionality.
>They get you started quickly but then you spend enormous amounts of time and energy customizing it to achieve the last few percent of functionality.
This is a good time to push back on requirements unless there's real money waiting to pay for that feature.
Usually things are not completely established up front, so you never have a good picture of things you're going to have to build with some dependency. In these situations, your choice of software and how well it supports future features may as well be a dice roll.
>In these situations, your choice of software and how well it supports future features may as well be a dice roll.
It's definitely a judgement call, and that's where having the experience to make that call correctly can save a ton of headache down the road. Some times YJGWI (You Just Gotta Write It).
Yep. This always happens in my experience. Or there is a bug fix or feature you badly need and it will never happen for various BS reasons. So now you either have to rip out the dependency and start all over or start maintaining a massive pile of garbage software that you didn’t even write (assuming you can even get access to the code).
> The caveat here is in the "if your team is competent",
Maybe it's from a place of privilege, but I have no interest in working where the team is not competent.
But, even if your team is incompetent, there's no guarantee of competence of the people who wrote the dependency you use instead of building it yourself. Most of the time, I'd rather deal with local incompetence than remote incompetence.
At the end of the day, if you want your project to work, you're responsible for the whole thing, include the dependencies you outsourced to others.
What makes you think that developers writing Commercial or Open Source libraries that you depend on are any better? Most software code is pretty bad. There aren’t many good developers out there. I would guess one in 20 maybe (30+ years of experience working for software companies in 5 countries).
An interesting outgrowth of NIH, including and especially places where the choice is defensible (as in the article), is that quite often the external dependency universe evolves or changes sufficiently to put you at a material disadvantage for not participating.
I worked somewhere in the 90s that had built its own database infrastructure to meet business requirements that existed in the early/mid 80s. If you set out to build the same system in 1995 that they'd built before, you absolutely would NOT use the same approach, but they plodded along with a mishmash of internally developed tech for a long, long time -- long enough that it really hurt them. And the first place that this damage showed up was in personnel. To be productive there, you had to know a ton about the internal tools that existed ONLY at 5251 Westheimer (<-- if you know, you know), which meant those skills were useless in the marketplace that was rapidly moving towards open-standards based development, etc., or at least using commercial databases.
It got hard to hire anybody but fresh kids, most of whom would split after 12-24 months.
So even if you do build your own C compiler or whatever, you have to keep an eye out for offramps to that internal dependency if the realities around your product or project change. In this sense, your internal dependency is no different than an external one -- you've always got to be looking for an alternative even if you're perfectly happy with the current path, because the current path might stop being viable.
Like everything, it depends, but yeah- "hitching your cart to a rocketship" is an important class of situation where it may be good to integrate with a dependency
> “California-style” campus in the trees along Cypress Creek ... in the outer suburbs of northwest Houston
google maps easily finds Cypress Creek, and it is really in northwest Houston, and it is 25 miles away from "5251 Westheimer Road, Houston TX", nowhere close.
Looks like ChatGPT was completely wrong. And those who claim that "but people will know ChatGPT can make mistakes, users will verify"... well, here is a counter-example, ChatGPT junk directly to comment field.
But, to be clear, was absolutely never at 5251 Westheimer.
Nor, to the best of my knowledge, were any software companies or restaurants or retail. It's an office building that was primarily leased by my former employer, which another commenter correctly noted was TeleCheck.
Has dang ever ruled on the appropriateness of this situation, where someone just redirects AI-generated output to their comment (absent any evaluative substance and on a digression from a digression fully unrelated to the discussion of AI)?
It strikes me as a bad-faith way to farm for low-effort internet points, but I'm just some idiot on the internet so I'll have to satisfy myself with a down-vote, a mild complaint, and a minute or two of wasted time.
I've definitely seen this in the wild -- certain accounts here post long-winded responses that at first glance seem very technical and hard to understand, but after a closer reading reveal it's just a mismatch of jargon intermixed with tangents.
The AI generated bullshit spam that will soon invade the net will appear here first. I've been ranting about openly-AI-generated content, profiles and comments on this forum before, to deaf ears and sneers calling me a Luddite.
I am quite tired of reading "I asked ChatGPT x and they said:", and it's been around for just 3 months.
Dang is quite equanimous, so I doubt he will take an open stance for or against it, but I dream he'd just come out and say "chill it with the GPT people. This place is for thoughtful discussion".
How did you get "certain sounding comment" from "However, it's important to note that this is just a possibility and I cannot say for certain that this is the company the person you mentioned was referring to without additional information."
I had a similar experience working for a company that had, essentially, developed their own in-house web templating language and programming system. They'd started before PHP or any of the other server-side programming languages had caught on, and while a decision to use a homebrew system may have been justifiable in the '90s, when the only real alternative was Perl/Mason, by the time I joined (2009), it was long overdue for them to have moved on to an industry-standard solution. PHP. Python/Django. Ruby/Rails. Even classic ASP would have been preferable to the mess of C++ and XML they were using.
Frankly, I think the article, like a lot of Joel Spolsky's writing, has aged like milk. For example:
If you’re developing a computer game where the plot is your competitive
advantage, it’s OK to use a third party 3D library. But if cool 3D effects
are going to be your distinguishing feature, you had better roll your own.
Except, if you look at modern games, even ones with very high performance effects, that's not what they do. They use one of a rather small number of 3D engines, like Unreal or Frostbite. It turns out that developing cool 3D effects is far easier if you have a battle-tested performance optimized framework helping you. CD Projeckt Red abandoned its own in-house engine (REDengine) in favor Unreal 5 for future development, in no small part due to the issues that they ran into trying to extend that engine for a massive open-world game like Cyberpunk 2077.
What changed is that 3D effects are no longer a distinguishing feature for games. By now, all modern AAAs look stunning, super-realistic is not as much of a selling point. Instead, you point with art, content and game play, most of which is very much developed in house.
The short version of the article is "don't outsource your core competency" and that very much holds true today.
Cyberpunk 2077 seems to be a very standard AAA game in terms of both gameplay and looks. It makes sense to use an established, popular engine there. It's also a perfect example of yet another somewhat forgettable experience.
Factorio or The Witness might be better examples of games that did/are doing novel, exceptional things and their engines were developed in-house. And it shows. The unique look and feel, the smoothness, depth, coherency etc.
The comparison is maybe unfair though. We're basically comparing a product focus with an art focus. Artists _must_ do things their way. Risk and cost are secondary. Success is a bonus. In a more survival oriented world you have to weigh these things differently.
What you describe above seems more like a problem with clinging to legacy and missing the world around them rather than developing things in-house. It should be obvious, but the thing you do in-house has to provide you unique advantages over the main-stream. That comes with costs and only works if you have the stomach to be honest with yourself.
> Factorio or The Witness might be better examples of games that did/are doing novel, exceptional things and their engines were developed in-house. And it shows
I dont think The Witness really required a custom engine, except that Mr. Blow had a team that could (and it might've been easier for them). Ditto with factorio tbh.
If a game like https://en.wikipedia.org/wiki/Antichamber could be done in unreal engine, most other games could've been done with it. The fact is, understanding the engine is harder than writing your own, and for some programmers, they'd rather write their own simply because they won't have to read someone else's code.
IJWTS that I paid my mortgage with Mason for a number of years in the early 2000s, and really loved it AT THE TIME.
On the one hand, there was no attempt to generate your DB code. OTOH, since you had to write it yourself, it was easy to tune.
100% agree with this take re: gaming, but his overall point -- if your value-add in the marketplace is X, you'd probably better build your own X -- is more true than not. Games blur that, but at the end of the day nobody buys games PURELY for the 3D side of things. They're looking for story and gameplay at least as much, and (for me at least) probably MORE than technical beauty.
> And the first place that this damage showed up was in personnel. To be productive there, you had to know a ton about the internal tools that existed ONLY at 5251 Westheimer (<-- if you know, you know), which meant those skills were useless in the marketplace that was rapidly moving towards open-standards based development, etc., or at least using commercial databases.
The other side of the coin here is that a team with some NIH code (if it is well engineered, modern, maybe open sourced or on its way to open sourcing) can use it to attract and retain certain engineers who might want to eg work on building a database or a compiler.
Now of course it's a pretty fine balance but I've worked at one non tech company that had basically no internal software projects whatsoever, and their engineering culture was abysmal. I think in that case they couldn't have made good software anyway but the fact that everything they did was pieced together from a handful of commercial vendors meant that there was no interesting code to write at all! For example, we were encouraged to report bugs to upstream paid support but never attempt to fix them, because they didn't want to deal with internal versions of software or open source licensing. I didn't stay for very long.
It's a balancing act and the balance is different based on the size of the companies and the specific product.
Fogbugz just got outcompeted by JIRA imo, and without the cross compiling that allowed it to run on linux (instead of just windows server) it would have been dead long long before.
> 3) For things that are not cryptography, I can usually write it better myself.
We've accepted specialization in most aspects of modern day society as a good thing. I fail to see, outside a small subset of programming, how you will always be able to write better code yourself for whatever domain you're working on.
> 5) I have a much better sense of what the code is doing this way.
> I fail to see, outside a small subset of programming, how you will always be able to write better code yourself for whatever domain you're working on.
Through practice.
But also, through realizing that when you look closely, many libraries are crap inside.
This feels to me like one of those "you have to learn these lessons to know how / when / why to apply the skill" types of things.
To the uninformed what your are doing looks insane. I think people project their fear of the "black box" that is "libraries" and forget that mere mortals like themselves wrote these tools to begin with.
The hard part is knowing when / what to re-use, and most importantly when you are ACTUALLY skilled enough to do it better and it makes sense to do so. There's a confluence of prevailing winds that makes this strategy possible or not possible.
> To the uninformed what your are doing looks insane. I think people project their fear of the "black box" that is "libraries" and forget that mere mortals like themselves wrote these tools to begin with.
This is what expertise looks like: it isn't Googlable, nor is it ChatGPTable.
You can get a rough idea of the quality of most libraries in about 10-20m typically, usually by playing with the library or browsing the code. Some red flags I look for: lack of tests, excessive number of commits, excessive number of dependencies, lack of focus in scope, etc.
One alternative I use frequently: lock dependencies up in a module, and write some glue code intended to act as the interface to that dependency. It is sometimes the case in which you have to use a library but it is not very good, or it has a horrible bug you can correct by exerting more precise control over how the library is called.
To add to the list of red flags are libraries which expect me to write callbacks and which don’t give me any control over the control flow in my program. A lot of messaging systems like QPID Proton do this. It’s like the developers couldn’t anticipate that I might want to wait on input from more than one file descriptor so they didn’t bother to build input handling separately from the core protocol that processes the input and yields state changes. I see an awful lot of crappy libraries that follow this pattern. It’s typified by a function or functions that take a file name or url and that expects you to register callbacks for everything. Typically they spawn tons of threads to interleave input. Then you have to poll with timers in a separate thread if you ever want to respond to input from eg a serial port alongside messages. It’s way more complicated than it needs to be.
> We've accepted specialization in most aspects of modern day society as a good thing. I fail to see, outside a small subset of programming, how you will always be able to write better code yourself for whatever domain you're working on.
It's strange that using fewer third-party dependencies has to be defended on a site called Hacker News.
Also, the code you NIH doesn't have to be superior to the third party code. It merely has to not get in the way for what you're doing. This is different from being "better," which has many dimensions to it. Example that comes to mind: I could reach for something like libuv, or I could just use POSIX for synchronization primitives. I'd prefer to the see the latter in most code unless there were explicit reasons for libuv, such as cross-platform support.
You're imagining you can get away with not understanding the third party code at all. That's never worked.
You need to have a working model of how a library works to use it in a performant way, which is why most libraries document their architecture, and have usage guidance.
And you'll find bugs, because there are always bugs. You need some strategy for what to do when that happens.
You're either one of the best developers in the world, or you think you are. If the former, then your system works well. If the latter, well, I'm glad it's been working for you so far, but I suspect you'll have trouble down the road.
And if you don't, it sounds like you'll never get your flywheel going so that you can stop working or work on something else.
I'm mostly saying, to people reading this, it would probably be unwise to follow this advice.
> You're either one of the best developers in the world
I'd say this is the approach used by anyone in the top 5% (give or take). Which is probably most of HN. You don't need to be Linus or Fabrice or DJB to know most programmers are bad at programming and realise you can do a better job.
Does that mean he writes his own kernel and C compiler? No, OP writes:
> I avoid using third-party libraries for anything I can write myself.
Which shows awareness of his current limits, another trait of good programmers.
I disagree. The more dependencies I remove, the less of a maintenance burden the code I maintain is. I am maintaining very large scale C++ code used in production every day by large multi-national companies. And have almost zero maintenance work.
Can you give more details about what you work on? Would you try to write something like libjpeg or sqlite3 yourself, or are those foundational libraries exceptions? If you're a web and/or application developer, do you implement your own frameworks?
libjpeg? Absolutely, it’s not that difficult if you read the spec and can do a bit of math. sqlite3? No, DBs do nasty things with filesystems and I would rather just rely on them to get it right.
Libraries like libjpeg solve one non-trivial problem and have been around forever and don't change very quickly. An implementation can be done by hand but it usually doesn't make sense to do so because the library has been around and stable long enough to be able to presume that it does it in a more performant way and is aware of possible gotchas that it avoids. A database is a large enough project that writing one every time you need one doesn't make any sense. It's probably more work than whatever you are working on. Using one that has been around for a while and that doesn't change quickly makes sense.
Grabbing a quick javascript library to do something relatively trivial that is going to bring in megabytes of supporting libraries whose provenance is unknown and that change often is a completely different matter.
I worked at a Java shop where they built their own "ORM." I use that term loosely. I showed up there about 4 years after this decision and was amazed by the WTFs I saw. Example: They weren't using prepared statements. Instead, they had some half baked escaping system that would occasionally trigger syntax errors in production.
The real advice here is build your core competencies. Another way to say this is "buy what you can, build what you can't", where "buy" includes using open source software.
When I'm choosing a new tool, I always look at if a solution already exists, and make a focused effort on determining all ongoing costs, such as maintenance, adding new features, managing the vendor relationship, etc. My preference is always to buy if it's something another company might need, because then I get the benefits of the features for that other company, but tempered with what my internal cost to build would be (including maintenance and adding new features).
I mean, sure - if I want to make sure my staff have a word processor and a spreadsheet, I'm going to buy Microsoft Office rather than writing it for myself.
On the other hand, for enterprise software, there's usually some seriously non-trivial integration cost - particularly if you're not starting from a green field. So the problem is "you can't buy a solution - you just need to decide how much of it you're going to build yourself according to your needs, and how much you're going to buy and tailor/integrate."
>> The real advice here is build your core competencies. Another way to say this is "buy what you can, build what you can't", where "buy" includes using open source software.
Except that the most valuable company in the world has consistently tried to own or control every part of their value chain, including businesses they had little experience with and probably no "core competency" in. And that's not an outcome of them having so much cash they can go into chip design, tv production, software tools etc. Steve Jobs would have made his own microprocessor in the '90s if he had the resources. Maybe that's the exception that proves the rule?
> Two yuppies in a living room buying an e-commerce engine from company A and selling merchandise made by company B and warehoused and shipped by company C, with customer service from company D, isn’t honestly adding much value.
It's funny he mentions this. I know someone who makes millions a year doing exactly this. Her value add is finding vendors, finding drop shippers, and marketing the products. But she doesn't build any tech or hold or make any inventory.
I've a cousin who does something similar, and also (according to him) makes in the high hundred-thousands/low million range. In theory, it sounds like easy money, but I personally would probably break down in tears from boredom if I had to work on drop-shipping widgets, even if I was raking in the cash.
> isn’t honestly adding much value...makes millions a year doing exactly this
if you are making money, you are adding value. You are putting products in front of people who want them at an attractive price for them. If you make the products from scratch and do that, or if you drag them the full length of the silk road, or if you buy a pack of cigarettes and stand outside and sell them as loosies, if people are buying from you, you're putting in your effort and making money which is the measure of value-add. Convenience stores can make money right next to lower priced supermarkets because walking accross the parking lot and to the back of the supermarket to get a quart of milk can feel like the silk road.
edit: downvoted for explaining how actual economics works? If you haven't studied economics, you shouldn't be making your feelings known, it's not a matter of opinion or preference, it's a field of study.
how is value-added tax calculated? on your feelings, or simply on how much money you make? QED
Ticket scalpers used to provide significant value. They provided liquidity in the market. If you wanted to get rid of some tickets you bought because you couldn't go anymore, you could sell them to scalpers. If you wanted last minute tickets to a popular event, you could buy them from scalpers.
But now that the venues manage their own secondary sales, the scalper is just extracting rent.
it is not extracting rent to sell something at the market price. They are engaging in almost riskless arbitrage because the OEM for the music or sports event sees some value in nominally pricing the event below market.
the reason ticket scalpers will never go away is that they provide a value added service, allowing people access to an event at a late date when they care more about the event than the money. You may not like that, you may think only true fans of an act who plan ahead should get to see the act, but the people who own the tickets don't feel the same way you feel, and they sell their tickets to people who have the right combination of more money and more desire to see the show.
My sister was coming to visit me in NYC, she's a huge Red Sox fan, I bought her and her friends Red Sox Yankees tickets, they had a blast. I was happy to have done it. The tickets were expensive. I got value for my money.
ticket scalpers are no different than stock brokers, I go to them when I want to buy shares of Tesla, and I have to pay the market price. They are the people who are willing to sit there and wait for my transaction without knowing if I'll ever show up, an activity that I don't want to engage in and I'm happy to pay them for it.
This is basically just the internet version of… any retailer that isn’t vertically integrated? Do we honestly think that Barrel & Crate’s business model is that different?
Yeah, you have a weak moat, but if your niche isn’t big then even a weak moat may not be worth crossing
Crate and Barrel holds inventory. They buy it in advance. Also I think they have items that you can't get anywhere else that are made special just for them?
I rewrote an 80 line thing about 20 times over the last 5 days. I'm still not happy with the way it looks and behaves.
There was nothing wrong with the first 150 line version (that was done in an hour or so) There are existing 3000ish line solutions too. They do many wonderful things that I don't need. I even had someone else write a version!
[Only] when it is done it will be added to the monolith of previous fumbles. It has a few things implemented quickly that will eventually get some careful reconsideration.
I'm fairly confident the final version will be a joy to look at for my future self. There wont be tests and there wont be any bugs.
> Indeed during the recent dotcom mania a bunch of quack business writers suggested that the company of the future would be totally virtual — just a trendy couple sipping Chardonnay in their living room outsourcing everything.
Kind of funny to read this, now that the practice is no longer a fantasy. I'm thinking of devs who have outsourced their jobs, and Amazon/Etsy sellers who simply resell/drop-ship goods from Alibaba.
Isn't that the whole point of trading goods? Making the match between producer and customer? IMHO there is no added value in rolling shipping, or having inventory.
> Kind of funny to read this, now that the practice is no longer a fantasy. I'm thinking of devs who have outsourced their jobs, and Amazon/Etsy sellers who simply resell/drop-ship goods from Alibaba.
One of the issues with being a middleman without a moat is that there's downward pressure on your margin over time until you are squeezed out of the market.
Given the amount of ads I get encouraging people to become a Amazon drop-shipper, I assume that making money doing that has got hard enough that selling shovels became more profitable.
I was doing it about 5 years ago, and it was mildly profitable without putting in a lot of effort. I see a lot more things dropshipped on amazon now, etc, so it would probably take a lot more effort now to make any serious money.
He makes some good points (as always) but the next interesting question is: "what if you really want to go in-house but currently don't have the talent". We run into that a lot and fail to hire experts from the outside because
a) it's difficult
b) our engineers want to develop the expertise themselves
Sometimes there are good reasons for b) but we often miss the boat.
I feel like you can cheat really hard with modern frameworks. Take something like .NET7 for example. You can get very far into some product before you need a piece of functionality that is simply not available in the first-party tool set.
If we wanted to NIH all the things, we'd have to start doing crazy shit like implementing our own JSON serializers or hand-rolling artisanal CSPRNG/SHA algorithms. We'd almost have to want to make our lives harder on purpose. There's no way we could make it look like it was in pursuit of a grander product outcome when the obvious answer is already being pushed on us by intellisense. We could try to lie to ourselves about all of this or paint various vendors in pale hues of evil, but none of this is fun or feels like much progress.
Starting with something that includes nearly 100% of the batteries takes a lot of the temptation out of the way. You won't even begin the dangerous "should I write it or vendor it" adventure because you will be so distracted with all of the features you are shipping.
> If we wanted to NIH all the things, we'd have to start doing crazy shit like implementing our own JSON serializers or hand-rolling artisanal CSPRNG/SHA algorithms.
These two are not analogous. Writing your own JSON deserializer/serializer can absolutely make sense depending on what you are doing. You'd better have a very good reason for writing your own sha algorithm.
Any sufficiently gifted programmer will reach a point where they realize that there is no third party tool that is quite right for the specific problem they are solving. The art is in identifying where exactly the line is. Personally, I tend to fall in the batteries not included camp but this only works in a high skill/trust environment, which frankly is not companies. You're probably right that in most cases preferring batteries included is a better default disposition. But almost definitionally these types of places will tend not to be technologically innovative.
> These two are not analogous. Writing your own JSON deserializer/serializer can absolutely make sense depending on what you are doing. You'd better have a very good reason for writing your own sha algorithm.
I mostly agree with you, but to me this is presented as a logically-inconsistent argument.
Why is writing my own JSON serializer relatively better than writing my own SHA implementation? Don't we first need to look at the actual problem? Why does it have to be a very good reason, as opposed to simply the same quality of reasoning used for the JSON decision?
> I was the program manager in charge of the first implementation of Visual Basic for Applications
Say it ain't so, Joe(l)! Never meet your heroes, I guess...
I've always enjoyed his take on things. I'm very much a "dependency skeptic."
As I watch disaster after disaster happen, fueled by The Dependapocalypse, I haven't seen much to dissuade me.
Sure, there's plenty of really awesome stuff out there, like Linux, Git, STL, etc., but there's also a lot of truly awful toxic sludge; much of it wrapped in sexy, jargon-filled Web sites, and with large user communities.
Part of my problem, is that I'm not really good at saying "Fuck it, let's ship," when the project is still unripe. I know that I've left a lot of money on the table, with that attitude, and have received torrents of scorn, as a result.
But. I. Just. Can't. Ship. Crap.
I just can't bear it. Call it a pathology.
It's difficult to truly vet a dependency. I suspect most people look for the biggest crowd of users, and a glitzy presentation.
Oh, and probably "free," as well.
I find that doing a lot of research on a library or SDK, takes a lot of really boring footwork, and time not spent writing sexy software.
Also, if I will be basing a business, or my reputation, on the work of others, I had better be prepared to pay for it; or at least, roll up my sleeves, and work hard for it.
> the market pays for value added
I'm not so sure about that. It seems that the market pays for garbage, and that a lot of people have gotten quite wealthy, selling it.
> It seems that the market pays for garbage, and that a lot of people have gotten quite wealthy, selling it.
The market pays for whatever solves their problem, even if it is garbage.
What the "hype-driven hustle" modern software has forgotten, is that the market would pay even more for software that solves their problem AND is not garbage. People value quality. 2023 software engineers don't, they just value time-to-ship, so we have garbage software everywhere valued billions, because people need it.
Want to disrupt any niche? Make really good software. Put power users first. Or at least this is the philosophy I strive to follow, we'll see if it pays off.
Do not ship crap. But also recognise you'll never be truly happy with the most polished of gems either. This is a very hard skill to learn, and there's few role models to follow.
> Want to disrupt any niche? Make really good software.
I really want you to be right.
I've found that high Quality tends to be fairly pricey. There's a reason a Mercedes costs three times as much as a Toyota, and the car doesn't seem to have many more features.
Incremental improvements in Quality can mean a great deal of extra time and detailing.
I see you enjoy Apple products, and I seem to remember you're older and you have more to teach me about the world but...
Wasn't Apple once the paragon for software quality? Didn't people flock to it when it was still incredibly expensive because it was objectively better made than the competition? I remember wishing my parents were richer and would buy me a Macintosh instead of having to use a PC.
A Ferrari costs more than a Toyota, but you have to decide if you want to make a car that sells a lot, or a premium car. Can't have both, but these days in software they're all making Ladas, and no one is shipping Mercedes, let alone a Ferrari.
Yeah, I feel as if the shine is wearing off of Apple.
I saw the company I worked for (once synonymous with "Quality") take a big hit, when they started making money, and selling in the millions, but they also got clobbered, and I hope they are going back to their Quality roots (although it may be too late).
Quality starts at the top. A Cook will never become a Jobs, and they make very few Jobs in our fields.
This is why I said we lack the role models. The philosophy of "ship, then fix" and VCs demanding a quick RoI creates a culture of Cooks. With all due respect to the guy, he is not a visionary nor an idealist.
The real lesson here, which is timeless, is that you're safer if you understand why your favorite rules of thumb got to be that way. Did you learn the hard way, from a particular set of circumstances? Do those still apply? Is it a natural consequence of lower level principles? Do you still believe those? Or maybe someone you respect told you to do it, or it just sounded good. Not bad reasons to do things, but knowing that's all you're working from gives you a hint that you should be opening to change your mind.
> The Not-Invented-Here Syndrome is considered a classic management pathology, in which a team refuses to use a technology that they didn’t create themselves.
Within the team yes; but my experience with management has been anything "Not-Invented-Here" is considered infallible and practically divine. Anything done in-house is subjected to the deepest level of scrutiny imaginable.
Always has seemed like its due to who they can pass the blame off to - If my team screwed up I'm liable, if an external vendor screws up we had no control over them.
As frustrating as NIH can be, Never-Invented-Here can be worse. I’ve worked in shops where we were doing some bleeding edge things, either with processes that scaled horizontally to levels that were ridiculous at the time, or by handling astounding numbers of events per second, etc. In some of those, we had tech leadership who felt very strongly about using off the shelf components wherever possible, which is fine. Most shops don’t need to re-invent Nginx, or PostgreSQL, or Redis. However, sometimes there’s something unique about a specific problem that means that nothing widely used is going to be a good fit. And in that case, you’ve gotta decide whether to 1) make your engineers solve it with an inadequate tool, 2) find a way to make the problem go away, e.g. by turning away big customers, or 3) trust your engineers to, you know, invent new things.
There's a quite common problem that could be called "Not Invented Here (because we bit off more than we could chew and didn't finish the project, missing the market opportunity)"
I love I can just pull in libraries in any language to solve X.
I hate that some builds pull in gigabytes of libraries for everything under the sun to replicate what was done 20 years ago with a few scripts and some HTML.
Yeah, it's a spectrum and not everyone is qualified to make the right call - but their job demands they choose anyway.
I thought for sure this was going to touch on the phenomenon that, "Most software works best with English/On English systems".
I remember hearing all about years ago how the domestic Japanese software market was behind that of the US in some ways, because companies just don't trust software from foreign companies. I don't know if it is still true, but among them was more of a focus on customer service and software maintenance, and as well the aforementioned tendency for software to work better with English.
Heck. I've built my own embedded in memory EAV database back in 2002 for exactly the same reasons Joel mentioned. It was major backend part of my product that provided me with healthy revenue at the time. There was no way I'd be in the mood of paying licensing fee to somebody else.
Putting aside the long-term concerns such as building skills, maintainability, team dynamics and so on, there's a simple effort-based cost-benefit analysis you can do. To responsibly use a bit of software Not Invented Here, you have to
(a) understand what it does
(b) research the available alternatives
(c) check that you're happy with its dependencies
(d) deal with any licensing issues
(e) check for known issues and bugs
(f) if possible, take it for a test run
which is likely to be a nontrivial amount of work. If it's less effort to just write it, you may be better off just writing it.
This is a good Joel post, but the bar has moved significantly.
"If it’s a core business function — do it yourself, no matter what". The question is, what is "Core Business Function"?
If you were an internal tech company in 2000s, hosting your own servers was a "core business function", as being a tech company meant that tech was core business function. However, as tech got more sophisticated, the domain of "core function" became more focused per company
Another example is the rise of fabless semiconductor companies. Even until recently, Intel had superior chip design and fabrication capabilities (thus intel's tick-tock strategy). AMD founder Jerry Sanders claimed "Real men have fabs" but AMD's spinoff of GlobalFoundaries look like a genius move now.
What you think of "core business function" is going to change over time.
To add, more and more of these "core business functions" had to be invented; nowadays you can get everything - from data persistence to push notifications to spinning up servers worldwide - set up in a short amount of time as long as you have a credit card.
I'm pretty sure now that most businesses / tech companies are glued components with a core idea and a lot of marketing attached to it.
> If you were an internal tech company in 2000s, hosting your own servers was a "core business function", as being a tech company meant that tech was core business function.
We have a modern version of this - people that aren't selling cloud services running their own Kubernetes farms rather than just buying cheap k8s or whatever other orchestration solution they like from a cloud hosting provider.
121 comments
[ 2.9 ms ] story [ 187 ms ] threadCost me some credit. Now I am trying to get us away from the awful mess we produced.
Excuse me WHAT? Is there a list of goofy MS decisions somewhere?
You could learn to properly use ANSI C, or you could write your own compiler instead for some subset of C and pretend like youre smart for it.
It would make sense why MSVC has pretty much no C support, and why so many MS products are so uniquely bad, instead of being bad in the same ways (uniformly)
One of the worst things about the modern internet is people can be so rude and disrespectful to people they've never met for decisions they know nothing about. The custom compiler was used in the 80s and early 90s for P-Code and was a way of dealing with the perceived proliferation of multiple CPU architectures, as well as producing significantly more dense code. This mattered a lot back then.
MS-DOS was written in assembly, and very stripped down and small, but office apps needed to be somewhat fatter with luxurious features so memory was an issue. Microsoft was working on a C compiler but wasn't selling it as a product (although, did they license Lattice C for awhile?) Ultimately, the cs compiler was added to Microsoft's C compiler as a p-code option. Ultimately ultimately people stopped caring about small memory and the utility of pcode went away.
I was already answering "it depends" on three of them.
> 1. Code Reuse is:
"Code reuse" sounds good, but if you abuse DRY ("Don't Repeat Yourself") then you can easily get into a mess that would have been more maintainable if it had been separate structs/classes/functions/modules in the first place, even if there's some duplicate code.
My rule of thumb is, if the purposes are different, then they should be separate things, even if the code is exactly the same line-for-line. When (if) it becomes obvious that we're always updating the code on multiple sides, then we can start considering combining them into only one thing.
It more or less aligns with the Rule of Three.
> 2. Reinventing the Wheel is:
It sounds "bad" because there's apparently "duplicate effort that you could have saved if you just used this library", but you have to remember that now you're at the mercy of this library, and unless you're paying for it, the maintainers can do whatever they want with it, including removing it or even using the name for a different thing (e.g. "tree-analyzer" being initially something related to ASTs (Abstract Syntax Trees), but then being re-purposed as an OpenCV tool to identify tree species (plants) from pictures).
And also following the wheel analogy, we can't forget that reinventing the wheel was necessary because modern cars can't use wheels destined for horse carriages; and airplanes can't use wheels used by cars. It wasn't just a matter of making an existing wheel thicker, or just using a different material; the whole build process is different.
> 3. The Not-Invented-Here Syndrome is:
The article sums this up nicely: "If it’s a core business function — do it yourself, no matter what."
He was bucking the prevailing wisdom a bit. We had gone from cowboy coder teams building everything themselves, to highly structured/abstract code bases. "Don't build if you can buy, don't roll your own if there's an existing tool, if you do build a tool, make sure you make it in a way that's reusable." Etc.
Here, Joel was saying that there are exceptions to the rule. That better teams should consider these exceptions before just leaning on the conventional wisdom.
I think in the decades since this article was first written, his way of thinking has become more common.
- can read the code, and
- is good at this technology, and
- has the domain specific knowledge to work on it,
but also someone who will be part of your team.
Further, NIH only works out well when youre not under strong pressure. Someone tells you to build XYZ, and you have NIH syndrome and build dependencies yourself, you will do so under a lot of time pressure, and it will be shit no matter how good you are.
It can go both ways though. You have the opposite of NIH, and say "there's no way in hell I have time to build this", so you pull in some huge unwieldy library that mostly solves the problem, and end up spending more time jamming a circle into a square hole and plugging up the gaps than you would have spent just solving the problem.
This is a good time to push back on requirements unless there's real money waiting to pay for that feature.
Usually things are not completely established up front, so you never have a good picture of things you're going to have to build with some dependency. In these situations, your choice of software and how well it supports future features may as well be a dice roll.
It's definitely a judgement call, and that's where having the experience to make that call correctly can save a ton of headache down the road. Some times YJGWI (You Just Gotta Write It).
Maybe it's from a place of privilege, but I have no interest in working where the team is not competent.
But, even if your team is incompetent, there's no guarantee of competence of the people who wrote the dependency you use instead of building it yourself. Most of the time, I'd rather deal with local incompetence than remote incompetence.
At the end of the day, if you want your project to work, you're responsible for the whole thing, include the dependencies you outsourced to others.
> there's no guarantee of competence of the people who wrote the dependency
This is, in my opinion, the best reason to build stuff in-house. Thank you!
I worked somewhere in the 90s that had built its own database infrastructure to meet business requirements that existed in the early/mid 80s. If you set out to build the same system in 1995 that they'd built before, you absolutely would NOT use the same approach, but they plodded along with a mishmash of internally developed tech for a long, long time -- long enough that it really hurt them. And the first place that this damage showed up was in personnel. To be productive there, you had to know a ton about the internal tools that existed ONLY at 5251 Westheimer (<-- if you know, you know), which meant those skills were useless in the marketplace that was rapidly moving towards open-standards based development, etc., or at least using commercial databases.
It got hard to hire anybody but fresh kids, most of whom would split after 12-24 months.
So even if you do build your own C compiler or whatever, you have to keep an eye out for offramps to that internal dependency if the realities around your product or project change. In this sense, your internal dependency is no different than an external one -- you've always got to be looking for an alternative even if you're perfectly happy with the current path, because the current path might stop being viable.
Here is a certain-sounding comment, which took me some time to read and verify. But Google search showed this post: https://www.houstonnwchamber.org/the-legacy-of-compaq/ which mentions
> “California-style” campus in the trees along Cypress Creek ... in the outer suburbs of northwest Houston
google maps easily finds Cypress Creek, and it is really in northwest Houston, and it is 25 miles away from "5251 Westheimer Road, Houston TX", nowhere close.
Looks like ChatGPT was completely wrong. And those who claim that "but people will know ChatGPT can make mistakes, users will verify"... well, here is a counter-example, ChatGPT junk directly to comment field.
Nor, to the best of my knowledge, were any software companies or restaurants or retail. It's an office building that was primarily leased by my former employer, which another commenter correctly noted was TeleCheck.
It strikes me as a bad-faith way to farm for low-effort internet points, but I'm just some idiot on the internet so I'll have to satisfy myself with a down-vote, a mild complaint, and a minute or two of wasted time.
See here, for one example: https://news.ycombinator.com/threads?id=Cullinet
I am quite tired of reading "I asked ChatGPT x and they said:", and it's been around for just 3 months.
Dang is quite equanimous, so I doubt he will take an open stance for or against it, but I dream he'd just come out and say "chill it with the GPT people. This place is for thoughtful discussion".
Frankly, I think the article, like a lot of Joel Spolsky's writing, has aged like milk. For example:
Except, if you look at modern games, even ones with very high performance effects, that's not what they do. They use one of a rather small number of 3D engines, like Unreal or Frostbite. It turns out that developing cool 3D effects is far easier if you have a battle-tested performance optimized framework helping you. CD Projeckt Red abandoned its own in-house engine (REDengine) in favor Unreal 5 for future development, in no small part due to the issues that they ran into trying to extend that engine for a massive open-world game like Cyberpunk 2077.The short version of the article is "don't outsource your core competency" and that very much holds true today.
Factorio or The Witness might be better examples of games that did/are doing novel, exceptional things and their engines were developed in-house. And it shows. The unique look and feel, the smoothness, depth, coherency etc.
The comparison is maybe unfair though. We're basically comparing a product focus with an art focus. Artists _must_ do things their way. Risk and cost are secondary. Success is a bonus. In a more survival oriented world you have to weigh these things differently.
What you describe above seems more like a problem with clinging to legacy and missing the world around them rather than developing things in-house. It should be obvious, but the thing you do in-house has to provide you unique advantages over the main-stream. That comes with costs and only works if you have the stomach to be honest with yourself.
I dont think The Witness really required a custom engine, except that Mr. Blow had a team that could (and it might've been easier for them). Ditto with factorio tbh.
If a game like https://en.wikipedia.org/wiki/Antichamber could be done in unreal engine, most other games could've been done with it. The fact is, understanding the engine is harder than writing your own, and for some programmers, they'd rather write their own simply because they won't have to read someone else's code.
On the one hand, there was no attempt to generate your DB code. OTOH, since you had to write it yourself, it was easy to tune.
100% agree with this take re: gaming, but his overall point -- if your value-add in the marketplace is X, you'd probably better build your own X -- is more true than not. Games blur that, but at the end of the day nobody buys games PURELY for the 3D side of things. They're looking for story and gameplay at least as much, and (for me at least) probably MORE than technical beauty.
Is TeleCheck really all that mysterious?
When were you there?
The other side of the coin here is that a team with some NIH code (if it is well engineered, modern, maybe open sourced or on its way to open sourcing) can use it to attract and retain certain engineers who might want to eg work on building a database or a compiler.
Now of course it's a pretty fine balance but I've worked at one non tech company that had basically no internal software projects whatsoever, and their engineering culture was abysmal. I think in that case they couldn't have made good software anyway but the fact that everything they did was pieced together from a handful of commercial vendors meant that there was no interesting code to write at all! For example, we were encouraged to report bugs to upstream paid support but never attempt to fix them, because they didn't want to deal with internal versions of software or open source licensing. I didn't stay for very long.
It's a balancing act and the balance is different based on the size of the companies and the specific product.
This led them to build Trello though, so maybe not a bad outcome?
1) I generally only need 10% of the library's functionality, and the rest is just extra weight.
2) I don't want to have to choose between freezing an old version of a library or having to update my code to integrate a new version.
3) For things that are not cryptography, I can usually write it better myself.
4) Third-party libraries typically do not prioritize accessibility or compatibility nearly as much as I do.
5) I have a much better sense of what the code is doing this way.
Edit: As jedberg helpfully pointed out, this post is not advice, and not intended to be treated as such.
We've accepted specialization in most aspects of modern day society as a good thing. I fail to see, outside a small subset of programming, how you will always be able to write better code yourself for whatever domain you're working on.
> 5) I have a much better sense of what the code is doing this way.
This is not scalable.
Through practice.
But also, through realizing that when you look closely, many libraries are crap inside.
> This is not scalable.
I specialize in things which do not scale.
To the uninformed what your are doing looks insane. I think people project their fear of the "black box" that is "libraries" and forget that mere mortals like themselves wrote these tools to begin with.
The hard part is knowing when / what to re-use, and most importantly when you are ACTUALLY skilled enough to do it better and it makes sense to do so. There's a confluence of prevailing winds that makes this strategy possible or not possible.
This is what expertise looks like: it isn't Googlable, nor is it ChatGPTable.
You can get a rough idea of the quality of most libraries in about 10-20m typically, usually by playing with the library or browsing the code. Some red flags I look for: lack of tests, excessive number of commits, excessive number of dependencies, lack of focus in scope, etc.
One alternative I use frequently: lock dependencies up in a module, and write some glue code intended to act as the interface to that dependency. It is sometimes the case in which you have to use a library but it is not very good, or it has a horrible bug you can correct by exerting more precise control over how the library is called.
It's strange that using fewer third-party dependencies has to be defended on a site called Hacker News.
Also, the code you NIH doesn't have to be superior to the third party code. It merely has to not get in the way for what you're doing. This is different from being "better," which has many dimensions to it. Example that comes to mind: I could reach for something like libuv, or I could just use POSIX for synchronization primitives. I'd prefer to the see the latter in most code unless there were explicit reasons for libuv, such as cross-platform support.
You need to have a working model of how a library works to use it in a performant way, which is why most libraries document their architecture, and have usage guidance.
And you'll find bugs, because there are always bugs. You need some strategy for what to do when that happens.
Fix them, I imagine. Which is easier if you're better at writing code than the author of whatever someone threw on (package manager of choice).
And if you don't, it sounds like you'll never get your flywheel going so that you can stop working or work on something else.
I'm mostly saying, to people reading this, it would probably be unwise to follow this advice.
I'd say this is the approach used by anyone in the top 5% (give or take). Which is probably most of HN. You don't need to be Linus or Fabrice or DJB to know most programmers are bad at programming and realise you can do a better job.
Does that mean he writes his own kernel and C compiler? No, OP writes:
> I avoid using third-party libraries for anything I can write myself.
Which shows awareness of his current limits, another trait of good programmers.
Grabbing a quick javascript library to do something relatively trivial that is going to bring in megabytes of supporting libraries whose provenance is unknown and that change often is a completely different matter.
When I'm choosing a new tool, I always look at if a solution already exists, and make a focused effort on determining all ongoing costs, such as maintenance, adding new features, managing the vendor relationship, etc. My preference is always to buy if it's something another company might need, because then I get the benefits of the features for that other company, but tempered with what my internal cost to build would be (including maintenance and adding new features).
On the other hand, for enterprise software, there's usually some seriously non-trivial integration cost - particularly if you're not starting from a green field. So the problem is "you can't buy a solution - you just need to decide how much of it you're going to build yourself according to your needs, and how much you're going to buy and tailor/integrate."
Except that the most valuable company in the world has consistently tried to own or control every part of their value chain, including businesses they had little experience with and probably no "core competency" in. And that's not an outcome of them having so much cash they can go into chip design, tv production, software tools etc. Steve Jobs would have made his own microprocessor in the '90s if he had the resources. Maybe that's the exception that proves the rule?
It's funny he mentions this. I know someone who makes millions a year doing exactly this. Her value add is finding vendors, finding drop shippers, and marketing the products. But she doesn't build any tech or hold or make any inventory.
if you are making money, you are adding value. You are putting products in front of people who want them at an attractive price for them. If you make the products from scratch and do that, or if you drag them the full length of the silk road, or if you buy a pack of cigarettes and stand outside and sell them as loosies, if people are buying from you, you're putting in your effort and making money which is the measure of value-add. Convenience stores can make money right next to lower priced supermarkets because walking accross the parking lot and to the back of the supermarket to get a quart of milk can feel like the silk road.
edit: downvoted for explaining how actual economics works? If you haven't studied economics, you shouldn't be making your feelings known, it's not a matter of opinion or preference, it's a field of study.
how is value-added tax calculated? on your feelings, or simply on how much money you make? QED
But now that the venues manage their own secondary sales, the scalper is just extracting rent.
My sister was coming to visit me in NYC, she's a huge Red Sox fan, I bought her and her friends Red Sox Yankees tickets, they had a blast. I was happy to have done it. The tickets were expensive. I got value for my money.
ticket scalpers are no different than stock brokers, I go to them when I want to buy shares of Tesla, and I have to pay the market price. They are the people who are willing to sit there and wait for my transaction without knowing if I'll ever show up, an activity that I don't want to engage in and I'm happy to pay them for it.
Yeah, you have a weak moat, but if your niche isn’t big then even a weak moat may not be worth crossing
There was nothing wrong with the first 150 line version (that was done in an hour or so) There are existing 3000ish line solutions too. They do many wonderful things that I don't need. I even had someone else write a version!
[Only] when it is done it will be added to the monolith of previous fumbles. It has a few things implemented quickly that will eventually get some careful reconsideration.
I'm fairly confident the final version will be a joy to look at for my future self. There wont be tests and there wont be any bugs.
Kind of funny to read this, now that the practice is no longer a fantasy. I'm thinking of devs who have outsourced their jobs, and Amazon/Etsy sellers who simply resell/drop-ship goods from Alibaba.
Find a cheaper way to do something Find a better way to market something
He wasn't wrong. End of the day, these kind of 'businesses' are merely exploiting a market inefficiency that won't last forever.
One of the issues with being a middleman without a moat is that there's downward pressure on your margin over time until you are squeezed out of the market.
Given the amount of ads I get encouraging people to become a Amazon drop-shipper, I assume that making money doing that has got hard enough that selling shovels became more profitable.
In other words, it's more profitable teaching people to become Amazon drop-shippers than it is to be one.
a) it's difficult
b) our engineers want to develop the expertise themselves
Sometimes there are good reasons for b) but we often miss the boat.
If we wanted to NIH all the things, we'd have to start doing crazy shit like implementing our own JSON serializers or hand-rolling artisanal CSPRNG/SHA algorithms. We'd almost have to want to make our lives harder on purpose. There's no way we could make it look like it was in pursuit of a grander product outcome when the obvious answer is already being pushed on us by intellisense. We could try to lie to ourselves about all of this or paint various vendors in pale hues of evil, but none of this is fun or feels like much progress.
Starting with something that includes nearly 100% of the batteries takes a lot of the temptation out of the way. You won't even begin the dangerous "should I write it or vendor it" adventure because you will be so distracted with all of the features you are shipping.
These two are not analogous. Writing your own JSON deserializer/serializer can absolutely make sense depending on what you are doing. You'd better have a very good reason for writing your own sha algorithm.
Any sufficiently gifted programmer will reach a point where they realize that there is no third party tool that is quite right for the specific problem they are solving. The art is in identifying where exactly the line is. Personally, I tend to fall in the batteries not included camp but this only works in a high skill/trust environment, which frankly is not companies. You're probably right that in most cases preferring batteries included is a better default disposition. But almost definitionally these types of places will tend not to be technologically innovative.
I mostly agree with you, but to me this is presented as a logically-inconsistent argument.
Why is writing my own JSON serializer relatively better than writing my own SHA implementation? Don't we first need to look at the actual problem? Why does it have to be a very good reason, as opposed to simply the same quality of reasoning used for the JSON decision?
Say it ain't so, Joe(l)! Never meet your heroes, I guess...
I've always enjoyed his take on things. I'm very much a "dependency skeptic."
As I watch disaster after disaster happen, fueled by The Dependapocalypse, I haven't seen much to dissuade me.
Sure, there's plenty of really awesome stuff out there, like Linux, Git, STL, etc., but there's also a lot of truly awful toxic sludge; much of it wrapped in sexy, jargon-filled Web sites, and with large user communities.
Part of my problem, is that I'm not really good at saying "Fuck it, let's ship," when the project is still unripe. I know that I've left a lot of money on the table, with that attitude, and have received torrents of scorn, as a result.
But. I. Just. Can't. Ship. Crap.
I just can't bear it. Call it a pathology.
It's difficult to truly vet a dependency. I suspect most people look for the biggest crowd of users, and a glitzy presentation.
Oh, and probably "free," as well.
I find that doing a lot of research on a library or SDK, takes a lot of really boring footwork, and time not spent writing sexy software.
Also, if I will be basing a business, or my reputation, on the work of others, I had better be prepared to pay for it; or at least, roll up my sleeves, and work hard for it.
> the market pays for value added
I'm not so sure about that. It seems that the market pays for garbage, and that a lot of people have gotten quite wealthy, selling it.
The market pays for whatever solves their problem, even if it is garbage.
What the "hype-driven hustle" modern software has forgotten, is that the market would pay even more for software that solves their problem AND is not garbage. People value quality. 2023 software engineers don't, they just value time-to-ship, so we have garbage software everywhere valued billions, because people need it.
Want to disrupt any niche? Make really good software. Put power users first. Or at least this is the philosophy I strive to follow, we'll see if it pays off.
Do not ship crap. But also recognise you'll never be truly happy with the most polished of gems either. This is a very hard skill to learn, and there's few role models to follow.
I really want you to be right.
I've found that high Quality tends to be fairly pricey. There's a reason a Mercedes costs three times as much as a Toyota, and the car doesn't seem to have many more features.
Incremental improvements in Quality can mean a great deal of extra time and detailing.
Wasn't Apple once the paragon for software quality? Didn't people flock to it when it was still incredibly expensive because it was objectively better made than the competition? I remember wishing my parents were richer and would buy me a Macintosh instead of having to use a PC.
A Ferrari costs more than a Toyota, but you have to decide if you want to make a car that sells a lot, or a premium car. Can't have both, but these days in software they're all making Ladas, and no one is shipping Mercedes, let alone a Ferrari.
I saw the company I worked for (once synonymous with "Quality") take a big hit, when they started making money, and selling in the millions, but they also got clobbered, and I hope they are going back to their Quality roots (although it may be too late).
This is why I said we lack the role models. The philosophy of "ship, then fix" and VCs demanding a quick RoI creates a culture of Cooks. With all due respect to the guy, he is not a visionary nor an idealist.
> Pick your core business competencies and goals, and do those in house
Within the team yes; but my experience with management has been anything "Not-Invented-Here" is considered infallible and practically divine. Anything done in-house is subjected to the deepest level of scrutiny imaginable.
Always has seemed like its due to who they can pass the blame off to - If my team screwed up I'm liable, if an external vendor screws up we had no control over them.
I hate that some builds pull in gigabytes of libraries for everything under the sun to replicate what was done 20 years ago with a few scripts and some HTML.
Yeah, it's a spectrum and not everyone is qualified to make the right call - but their job demands they choose anyway.
I remember hearing all about years ago how the domestic Japanese software market was behind that of the US in some ways, because companies just don't trust software from foreign companies. I don't know if it is still true, but among them was more of a focus on customer service and software maintenance, and as well the aforementioned tendency for software to work better with English.
(a) understand what it does
(b) research the available alternatives
(c) check that you're happy with its dependencies
(d) deal with any licensing issues
(e) check for known issues and bugs
(f) if possible, take it for a test run
which is likely to be a nontrivial amount of work. If it's less effort to just write it, you may be better off just writing it.
"If it’s a core business function — do it yourself, no matter what". The question is, what is "Core Business Function"?
If you were an internal tech company in 2000s, hosting your own servers was a "core business function", as being a tech company meant that tech was core business function. However, as tech got more sophisticated, the domain of "core function" became more focused per company
Another example is the rise of fabless semiconductor companies. Even until recently, Intel had superior chip design and fabrication capabilities (thus intel's tick-tock strategy). AMD founder Jerry Sanders claimed "Real men have fabs" but AMD's spinoff of GlobalFoundaries look like a genius move now.
What you think of "core business function" is going to change over time.
I'm pretty sure now that most businesses / tech companies are glued components with a core idea and a lot of marketing attached to it.
We have a modern version of this - people that aren't selling cloud services running their own Kubernetes farms rather than just buying cheap k8s or whatever other orchestration solution they like from a cloud hosting provider.
Most of those components are written by people who don't seem to understand HTML and CSS.
I worked on an app where a third party component was used to show a box, with some initials in it, and a background color. It was five divs.