8 ms·

In Defense of Not-Invented-Here Syndrome (2001)

143 points by sph 4y ago

F-W-M 4y ago
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.
lionkor 4y ago
> I guess that explained why Excel had its own C compiler. Excuse me WHAT? Is there a list of goofy MS decisions somewhere?
- sph 4y ago
  TFA explains why this goofy decision was one of the reasons behind Excel's success, and it is the point of the entire article.
  - lionkor 4y ago
    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)
    - mwcampbell 4y ago
      Remember though, Excel development started in the mid 80s, before ANSI C was even standardized.
      - lionkor 4y ago
        Yeah nevermind - I can't edit my comment now, but I was clearly not thinking about this.
    - jdsully 4y ago
      > 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.
- fsckboy 4y ago
  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.
quectophoton 4y ago
> Time for a pop quiz. 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."
- bena 4y ago
  The article is now two decades old. 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.
lionkor 4y ago
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.
- ramesh31 4y ago
  > 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.
  - brundolf 4y ago
    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
  - rqtwteye 4y ago
    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.
ubermonkey 4y ago
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.
- yen223 4y ago
  This applies to choosing external dependencies as well. Startups that chose FlowTypes over Typescript are struggling right now.
  - hamandcheese 4y ago
    What Flow lacks in community adoption, it makes up for in speed for a large codebase. Not feeling much pain yet (though I am worried about it).
    - deleted 4y ago
      [deleted]
- brundolf 4y ago
JamesBarney 4y ago
Didn't Joel run into problems building their own compiler with FogBugz?
- beckingz 4y ago
  My understanding is that it effectively killed FogBugz as the software aged. This led them to build Trello though, so maybe not a bad outcome?
  - eYrKEC2 4y ago
    When I used fogbugz, I loved it. I'd take it every day of the week instead of jira.
  - e2021 4y ago
    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.
forgotmypw17 4y ago
I avoid using third-party libraries for anything I can write myself. 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.
- richwater 4y ago
  > 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. This is not scalable.
  - forgotmypw17 4y ago
    > 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 is not scalable. I specialize in things which do not scale.
    - dirtybirdnj 4y ago
      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.
brundolf 4y ago
Joel's posts are always so good. Content and presentation
jedberg 4y ago
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).
- NovemberWhiskey 4y ago
  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."
- georgeecollins 4y ago
  >> 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?
jedberg 4y ago
> 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.
- mjevans 4y ago
  Sounds like a store / shop / service provider to me.
- RoddaWallPro 4y ago
  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.
- deleted 4y ago
  [deleted]
- fsckboy 4y ago
  > 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
6510 4y ago
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.
gnicholas 4y ago
> 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.
- deleted 4y ago
  [deleted]
- splitstud 4y ago
  Adding value propositions: 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.
  - funnym0nk3y 4y ago
    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.
- gav 4y ago
  > 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.
  - yCombLinks 4y ago
    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.
zwieback 4y ago
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.
bob1029 4y ago
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.
- thefaux 4y ago
  > 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.
  - bob1029 4y ago
    > 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?
ChrisMarshallNY 4y ago
> 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.
- deleted 4y ago
  [deleted]
- sph 4y ago
  > 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.
thenoblesunfish 4y ago
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.
quickthrower2 4y ago
One part hyperbole, two parts strawmen. Then later, buried in the diatribe is the sensible and somewhat trite sentence that can serve as your tl;dr: > Pick your core business competencies and goals, and do those in house
angry_moose 4y ago
> 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.
kstrauser 4y ago
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.
- fsckboy 4y ago
  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)"
Xeoncross 4y ago
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.
RajT88 4y ago
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.
FpUser 4y ago
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.
mjw_byrne 4y ago
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.
jeeyoungk 4y ago
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.
- Cthulhu_ 4y ago
  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.
- nailer 4y ago
  > 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.
nailer 4y ago
I feel this. People often want to stick with React, despite it being overly complicated, because of the 'huge variety of third party components'. 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.
pards 4y ago
> If you have customers, never outsource customer service. Words to live by
deterministic 4y ago
> Find the dependencies — and eliminate them One of the smartest things you can do in software development. In my experience, 99% of problems are caused by dependencies. Code that I wrote 20 years ago still works today. With no drama, no upgrade issues, no political BS, no waiting forever to get a simple bug fixed etc. The more dependencies I remove, the more reliable and maintainable my software is. For example: I am currently the maintainer of very large scale mission critical software written in C++ used by enterprises around the world. And I have reduced dependencies to almost zero. The result is zero bugs in production the last 5+ years. And zero maintenance pain. The result is that I spend close to 100% of my time adding features, improving performance etc. and close to 0% of my time dealing with dependency bugs/issues/open source politics/BS etc. It’s a great place to be!

143 points by sph 4y ago

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.

lionkor 4y ago

> I guess that explained why Excel had its own C compiler. Excuse me WHAT? Is there a list of goofy MS decisions somewhere?

sph 4y ago
TFA explains why this goofy decision was one of the reasons behind Excel's success, and it is the point of the entire article.
- lionkor 4y ago
  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)
  - mwcampbell 4y ago
    Remember though, Excel development started in the mid 80s, before ANSI C was even standardized.
    - lionkor 4y ago
      Yeah nevermind - I can't edit my comment now, but I was clearly not thinking about this.
  - jdsully 4y ago
    > 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.
fsckboy 4y ago
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.

quectophoton 4y ago

> Time for a pop quiz. 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."

bena 4y ago
The article is now two decades old. 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.

lionkor 4y ago

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.

ramesh31 4y ago
> 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.
- brundolf 4y ago
  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
- rqtwteye 4y ago
  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.

ubermonkey 4y ago

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.

yen223 4y ago
This applies to choosing external dependencies as well. Startups that chose FlowTypes over Typescript are struggling right now.
- hamandcheese 4y ago
  What Flow lacks in community adoption, it makes up for in speed for a large codebase. Not feeling much pain yet (though I am worried about it).
  - deleted 4y ago
    [deleted]
brundolf 4y ago

JamesBarney 4y ago

Didn't Joel run into problems building their own compiler with FogBugz?

beckingz 4y ago
My understanding is that it effectively killed FogBugz as the software aged. This led them to build Trello though, so maybe not a bad outcome?
- eYrKEC2 4y ago
  When I used fogbugz, I loved it. I'd take it every day of the week instead of jira.
- e2021 4y ago
  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.

forgotmypw17 4y ago

I avoid using third-party libraries for anything I can write myself. 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.

richwater 4y ago
> 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. This is not scalable.
- forgotmypw17 4y ago
  > 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 is not scalable. I specialize in things which do not scale.
  - dirtybirdnj 4y ago
    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.

brundolf 4y ago

Joel's posts are always so good. Content and presentation

jedberg 4y ago

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).

NovemberWhiskey 4y ago
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."
georgeecollins 4y ago
>> 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?

jedberg 4y ago

> 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.

mjevans 4y ago
Sounds like a store / shop / service provider to me.
RoddaWallPro 4y ago
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.
deleted 4y ago
[deleted]
fsckboy 4y ago
> 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

6510 4y ago

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.

gnicholas 4y ago

> 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.

deleted 4y ago
[deleted]
splitstud 4y ago
Adding value propositions: 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.
- funnym0nk3y 4y ago
  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.
gav 4y ago
> 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.
- yCombLinks 4y ago
  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.

zwieback 4y ago

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.

bob1029 4y ago

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.

thefaux 4y ago
> 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.
- bob1029 4y ago
  > 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?

ChrisMarshallNY 4y ago

> 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.

deleted 4y ago
[deleted]
sph 4y ago
> 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.

thenoblesunfish 4y ago

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.

quickthrower2 4y ago

One part hyperbole, two parts strawmen. Then later, buried in the diatribe is the sensible and somewhat trite sentence that can serve as your tl;dr: > Pick your core business competencies and goals, and do those in house

angry_moose 4y ago

> 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.

kstrauser 4y ago

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.

fsckboy 4y ago
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)"

Xeoncross 4y ago

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.

RajT88 4y ago

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.

FpUser 4y ago

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.

mjw_byrne 4y ago

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.

jeeyoungk 4y ago

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.

Cthulhu_ 4y ago
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.
nailer 4y ago
> 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.

nailer 4y ago

I feel this. People often want to stick with React, despite it being overly complicated, because of the 'huge variety of third party components'. 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.

pards 4y ago

> If you have customers, never outsource customer service. Words to live by

deterministic 4y ago

> Find the dependencies — and eliminate them One of the smartest things you can do in software development. In my experience, 99% of problems are caused by dependencies. Code that I wrote 20 years ago still works today. With no drama, no upgrade issues, no political BS, no waiting forever to get a simple bug fixed etc. The more dependencies I remove, the more reliable and maintainable my software is. For example: I am currently the maintainer of very large scale mission critical software written in C++ used by enterprises around the world. And I have reduced dependencies to almost zero. The result is zero bugs in production the last 5+ years. And zero maintenance pain. The result is that I spend close to 100% of my time adding features, improving performance etc. and close to 0% of my time dealing with dependency bugs/issues/open source politics/BS etc. It’s a great place to be!