Ask HN: Opposite of not invented here?

> I am not keen to maintain code and have to answer questions from every Tom, Dick and Harry

This seems like the wrong attitude. Software development is about writing and maintaining code. If you need to solve a problem that is not cleanly solved by an existing library, it's your job to write the code, maintain it, and help your co-workers use it.

Remember, the people who wrote those open-source libraries are humans like you. They had enough confidence and experience to feel comfortable releasing their work to the world, but they are not super-geniuses. You can confirm this by looking at the source code of a typical open-source library :).

Personally, I prefer to avoid third-party libraries that impose a lot of structure on my code. My ideal third-party library is one that implements a single, complicated function (or family of functions), like solving a linear system of equations. In these cases using the library is an obvious choice. In cases where the library (framework) forces you to change the architecture of your application, you should think deeply about whether or not it's worth it.

I guess the overall message is: take ownership of your work.

In large enterprises you see the opposite of NIH. There isn't a name for it but it's something to the tune of "You never get fired for choosing IBM."

I remember constantly fighting for the right to develop the important software in-house rather than trying to cram them into a Salesforce app or buy some [x]-as-a-Service that does 60% of what you need and gives you 0% competitive advantage or intellectual property.

There's reasons for both approaches but you should never be too far in either direction.

For the organisational form, I've heard "never invent here."

Wikipedia says "proudly found elsewhere" or "invented elsewhere" are commonly used. I've heard the latter one before.

https://en.wikipedia.org/wiki/Not_invented_here

Neither of those are quite strong enough, I think. Some organisations have a great reluctance to build anything new even when there's a clear need. Hence never invent.

What would be the choice/dividing line on what to build vs rent(saas)/buy?

Don't buy things that are part of your core business. (If your business is creating a word processor, don't buy a rich text box control)

Do buy things that are commodities and outside of your domain specific expertise. Accounting software (assuming you aren't an accounting software company). CRM software. Rich text controls.

Build things that give you a competitive advantage over other companies in your sector.

This becomes more complex depending what industry you are in. Take mobile networks no mobile opco has the engineering talent to build their own switches, bsc or ns. One could say this is part of their core business. Yet they buy this.

Exactly. At a "all hands meeting" of the IT staff of large food manufacturer (top 5 globally), I asked if there was room for developing our own solutions sometimes (since we complained so much about our current tools and the lack of alternatives). I got an angry response from the CTO and later discovered people were laughing about my proposal (either because I must be stupid or because I was certaintly joking, in their view).

I wasn't talking about writing our own ERP, my area was server infrastructure and there was tons of automation we could be creating, but instead the general strategy was to buy off-the-shelf tools and pay to be cheated on by IT consultants.

The almost complete inability of the IT area to take ownership of its own fate made me leave 6 months later. "Nobody gets fired by choosing IBM" syndrome in full effect.

> [...] I asked if there was room for developing our own solutions sometimes [...]

> [...] my area was server infrastructure

You see, a sysadmin in such an environment is not expected to write programs. That's not in his job description. On the other hand, he probably is free to write scripts and configuration.

I never bothered with asking if I, as a sysadmin, can write a service that I will use myself, nor I bothered with asking what language should I use. (This way I learned Erlang.) My job was to keep services running as intended, and how -- it was up to me.

It would need to be very hostile environment to prevent sysadmins from writing their tools. Though your last paragraph suggests it was hostile.

There are essentially four scenarios - you make the "safe" choice and succeed, and you're smart - if you fail, well, you can't be blamed, the safe choice is conventional wisdom.

You make the risky/bold/nonconventional choice and succeed, and you're lucky - fail, well, you're an idiot who should've seen it coming.

As pointed out in another comment, analysis paralysis is the term you're looking for here. One strategy to get past it is to timebox the analysis phase. For instance, give yourself two days (or however long is reasonable) to spend on research, but no more. At the end of the two days your should either have a clear answer or you will have run out of time and need to make a decision based on imperfect information. Realize that information is always imperfect and most times the options won't impact the end result in very different ways (otherwise the answer would've been clear), so there's a lot of benefit to just getting started. Decisions can be reversed as well, so nothing is final.

"A good plan violently executed now is better than a perfect plan executed next week." - George S. Patton

Thanks, I like the idea of setting a rigid time frame for analysis.

"A good plan violently executed now is better than a perfect plan executed next week." - George S. Patton

Thank you. I had never heard this. My ex was career military and he always said "Sometimes, a ninety percent solution now is better than a one hundred percent solution later." That appears to be what filtered down into military culture from Patton's remark. (FWIW: My ex's first duty station was a former Patton unit.)

For the OP, I will add that I find some of the following rubrics generally useful:

1) Assign X amount of time for research or thinking on it. Pick a date/ time when you will decide/execute. When that date/time arrives, you are done researching/cogitating. It is time to do something.

2) Take a break between thinking/researching and acting. Do your research before lunch and execute after lunch or do your research late in the day and execute the follow morning after sleeping on it.

3) Track performance metrics. Get hard data and see if your actual performance is really as bad as you think it is. Often, very competent or knowledgeable people have endless criticisms of their own work because they are more aware of defects or potential defects. Mediocre performers often think they did better than they did because they are oblivious to how bad it is. The solution here is objective measures of performance. Humans are tremendously bad at figuring out how well they are doing based on subjective feelings or opinions.

4) Anything worth doing is worth doing badly. In other words, partial solutions are better than no solution. Though, to be fair, this is basically another take on the Patton quote and the military rubric I am familiar with.

Best.

"premature optimization is the root of all evil"

I think you're conflating NIH with "willing to write code that isn't absolutely perfect."

I think your paralysis is coming from perfectionism.

We all want to build the Eiffel Tower and Mars rovers, things meant to be temporary but end up being elegant and lasting for much longer than ever intended.

None of us want to build things like the Tacoma Bridge, things with inherit flaws that are disasters.

But in the end, remember, most of what we build are really just kitchen tables and midrange houses. We should take pride in our work and do our due-diligence, but in the end, we have to ship code.

I've recently come to realize I've been afflicted with analysis paralysis. It stems from perfectionism and leads to procrastination. I have found How to Be an Imperfectionist: The New Way to Self-Acceptance, Fearless Living, and Freed from Perfectionism ( http://amzn.to/2dyrWcM ) to be very eye opening and helpful in overcoming perfectionism.

You comment does strike a cord with me. At the end of the day it is about shipping code.

At the end of the day its about solving problems. No one pays a programmer to "ship code". If that problem is solved by someone elses code, use that perhaps.

My favourite cases are those where that problem is solved by removing code.

I feel so proud of - line pull requests. Especially if I added a test too.

I am familiar with the idea (and have felt it in the past), but the best approach I have found for most places (less than 10k engineers on staff) is, "be very careful that you only invent things that are core to your needs."

The greater internet population will move faster than your internal team, and your beautiful snowflake will be supplanted with a better OSS option much more quickly than you expect if it is not a core driver of what you are doing. Your time and attention will necessarily shift to the core once the non-core is good enough. Therefore, you are almost always better off contributing to something external for non-core software rather than reinventing internally.

So, if it is core to what you do then build it yourself and maintain (possibly shared) control of it. If it is core to what you do but is not differentiating, open source it and drive to create a real community around it (so that it is the thing that keeps getting better, and you already use it!) If it is core and differentiating, then you are talking product strategy and there is no pat answer :-)

(edit, minor grammar fix)

Sounds a little bit like Analysis Paralysis[1], although I'm not sure I'd exactly call that "the opposite of NIH".

[1]: https://en.wikipedia.org/wiki/Analysis_paralysis

The opposite of NIH is Tinker Toy. You just glue existing bits together. This can work, but usually only on problems that have been solved before, and therefore have OSS software available.

A good example I experienced personally is data pipeline / job management. Six years ago there wasn't much out there, and at Facebook they developed DataSwarm. Today there are many decent OSS choices out there, including AirBnB's Airflow, Oozie, and Apache NiFi which was developed by the NSA.

The opposite of "not invented here syndrome" is "the new shiny."

In this condition, organizations culturally select new tools over older ones simply because they are new, get a lot of buzz among a certain userbase, and make extravagant promises of solving major problems with a tiny fraction of the amount of work that previous solutions required, due to some magical new technology or insight that the old school way of doing things didn't have.

Of course, in almost all cases "the new shiny" does not actually solve the problem with less work; it simply shifts the work around some -- frequently by moving upfront work into technical debt, unmaintainability, and non-extensibility. The usual net effect is to multiply rather than reduce the original problem -- but this is deferred into the future, so it's not usually noticed by "new shiny" enthusiasts and communities for some time.

The canonical example of "the new shiny" is NoSQL, which promised to simplify the design and scaling problems associated with relational databases. This is true when your app is tiny, but at any scale and after any amount of time, both of these problems become much worse. You just don't notice until much later, because the work has been shifted from upfront work to amortized work.

For your example, NoSQL is not likely to be replacing your internal database, or being used in place of an internal database software... it's in place of another vendor's database software. Trading one not invented here for another.

The opposite of not invented here would be a company that refuses to develop anything internally.

Ah I get where you are coming from. New projects often get more funding and attention than enhancements to existing software. Is the software I am developing actually solving the problem (the new shiny in your words) or adding another maintenance layer.

Partially. It's also about perceptions. People who are having a problem love to believe that there is a magic silver bullet solution out there somewhere -- one that will let them have to do a lot less work than the Old Way. It also makes them feel superior to the ignorant followers of the Old Way.

Install library X or buy app Y and all your problems will magically go away, and you're awfully clever if you realize this is the case, versus the unenlightened who continue to do things the Old Way. This is the basis of most sales and marketing techniques.

Frameworks and 3rd party libraries do not solve problems. Programmers solve problems.

Understand the problem you're trying to solve. Do you need a complicated dependency injection framework when establishing a design pattern is a better choice? Do you need a complicated ORM when a few pages of data-access code is a better choice?

Remember, 3rd party libraries aren't free: They have bugs, they need to be updated, they need to pass muster with the lawyer, ect. When you need to update a 3rd party library, it might cause regressions. Complicated frameworks can sometimes take a long time to learn to use correctly.

Another problem that some people explained is that 3rd party libraries can often force particular design decisions into your product, or require that you reference them all over your product. If this is the case, make sure to think carefully about your design patterns and make sure that the library pushes you towards patterns that are appropriate for what you're building.

Thus, you need to make sure that the 3rd party library is easier / cheaper / faster than whatever you can write, given the disadvantages that I explained above.

I've heard the phrase "never invented here" syndrome, but that doesn't seem to be what you're getting at. That term refers to a kind of disfunction where people are so terrified to the NIH syndrome that they'll shoehorn into an existing application, no matter how much contortion is required, simply to avoid developing their own code base.

That is an interesting angle. Part of my problem is that I work in a huge corporate company that has been around around a while so has quite a number of legacy systems. I am loathe to introduce new layers of complexity and that does sound like "never invented here" as you describe it.

I would agree that adding a new layer of complexity is to no one's advantage. A strangler application that becomes symbiotic with it's host can be a terrible thing.

I think the key angle to always consider: how will this new thing reduce overall complexity, now or over time? Maybe it means biting off a smaller chunk of the problem then you would like to keep the overall system sane. Or on the flip-side, keeping the new thing under wraps longer and running it in parallel with so you can thoroughly vet it before attempting to replace it.

And sometimes, you just have to decide that you won't be the person to try to 'repair' an application, particularly an old and stable one. Make the point change necessary for your need, call it a day and look for better opportunities elsewhere within the environment.

Do the best you can today. If someone has an issue with the result, either they'll fix it or you'll have the opportunity to fix it yourself.

Live with the shortcomings until you see a demonstrated need to fix them. Usually by that point, you'll have a better idea of how to get around it as well. You'll avoid doing extra work early.

Thanks for the advice.

If your team is filled with not invented here types and you resist that they make think you're lazy. That's my experience, and I can be lazy but I like to think it's in a good way.

Prior related discussion: https://news.ycombinator.com/item?id=9112885