[HN Gopher] In Defense of Not-Invented-Here Syndrome (2001)
___________________________________________________________________
In Defense of Not-Invented-Here Syndrome (2001)
Author : sph
Score : 100 points
Date : 2023-02-11 07:36 UTC (2 days ago)
(HTM) web link (www.joelonsoftware.com)
(TXT) w3m dump (www.joelonsoftware.com)
| JamesBarney wrote:
| Didn't Joel run into problems building their own compiler with
| FogBugz?
| beckingz wrote:
| 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?
| mjw_byrne wrote:
| 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.
| RajT88 wrote:
| 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.
| 6510 wrote:
| 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.
| forgotmypw17 wrote:
| 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.
| strken wrote:
| 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?
| rand_flip_bit wrote:
| 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.
| jedberg wrote:
| 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.
| forgotmypw17 wrote:
| I agree with jedberg. Please do not treat my post as advice.
| Nowhere did I state that it is intended as such.
| bluedino wrote:
| I've worked for you!
| icedchai wrote:
| 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.
| richwater wrote:
| > 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 wrote:
| > 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 wrote:
| 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.
| mattgreenrocks wrote:
| > 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.
| mattgreenrocks wrote:
| > 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.
| thenoblesunfish wrote:
| 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 wrote:
| 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
| brundolf wrote:
| Joel's posts are always so good. Content and presentation
| lionkor wrote:
| > I guess that explained why Excel had its own C compiler.
|
| Excuse me WHAT? Is there a list of goofy MS decisions somewhere?
| sph wrote:
| 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 wrote:
| 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)
| jdsully wrote:
| > 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.
| mwcampbell wrote:
| Remember though, Excel development started in the mid 80s,
| before ANSI C was even standardized.
| Xeoncross wrote:
| 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.
| angry_moose wrote:
| > 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.
| bob1029 wrote:
| 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 wrote:
| > 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 wrote:
| > 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?
| quectophoton wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| rqtwteye wrote:
| 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.
| vsareto wrote:
| >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.
| brundolf wrote:
| 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
| toast0 wrote:
| > 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.
| F-W-M wrote:
| 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.
| jedberg wrote:
| 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).
| georgeecollins wrote:
| >> 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?
| NovemberWhiskey wrote:
| 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."
| FpUser wrote:
| 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.
| gnicholas wrote:
| > _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.
| gav wrote:
| > 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 wrote:
| 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.
| [deleted]
| splitstud wrote:
| 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.
| ubermonkey wrote:
| 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.
| quanticle wrote:
| 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.
| Sebb767 wrote:
| 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.
| FrojoS wrote:
| I asked chatGpt to find out which company you are referring to:
|
| > Someone mentioned a company that is located at "5251
| Westheimer". Which company could this be?
|
| There are several companies located at 5251 Westheimer Road,
| Houston, TX 77056, United States, so I'm unable to determine
| which specific company the person you mentioned is referring to
| without further context. Some of the businesses located in that
| building include restaurants, retail stores, and offices.
|
| > It is or was a software company.
|
| I apologize, but without a specific name, it's difficult to
| determine the exact software company located at 5251 Westheimer
| Road in Houston, TX. There are many software companies located
| in Houston and it's possible that the company has since moved
| or changed its name.
|
| You may consider reaching out to the person who mentioned the
| company for additional information or searching online for
| software companies located in Houston, TX to see if you can
| find a match.
|
| > It was apparently a big company, big enough to develop a lot
| "in house".
|
| If the company was big enough to develop a lot of software in-
| house, it's possible that the company you're referring to is
| Compaq. Compaq was a large computer company that was
| headquartered in Houston, Texas and was one of the largest
| suppliers of personal computers in the world. The company was
| acquired by Hewlett-Packard (HP) in 2002.
|
| 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.
| theamk wrote:
| I think this a great example of why people don't like
| ChatGPT.
|
| 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.
| runnerup wrote:
| Compaq has moved a few times since 1995 and being absorbed
| by another megacorp.
| forevergreenyon wrote:
| your own post is the real counter-example.
| InitialLastName wrote:
| 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.
| qotgalaxy wrote:
| [dead]
| m463 wrote:
| he said - your core business - does infrastructure count?
| brundolf wrote:
| 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
| jedberg wrote:
| > 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.
| [deleted]
| mjevans wrote:
| Sounds like a store / shop / service provider to me.
| fsckboy wrote:
| > _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
| vageli wrote:
| By this logic, ticket scalpers provide significant value.
| thefaux wrote:
| Ticket scalping creates jobs and is a progressive tax on
| the wealthy. Both conservatives and liberals should love
| it! /s
| lmm wrote:
| As someone with a day job who can't stand in line or keep
| refreshing a website at the right moment, yes, they
| absolutely do.
| fsckboy wrote:
| 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.
| jedberg wrote:
| 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.
| fsckboy wrote:
| 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.
| RoddaWallPro wrote:
| 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.
| zwieback wrote:
| 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.
| ChrisMarshallNY wrote:
| _> 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]
| kstrauser wrote:
| 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 wrote:
| 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)"
___________________________________________________________________
(page generated 2023-02-13 23:01 UTC)