Ask HN: Opposite of not invented here?
I am familiar with the [not invented here syndrome](https://en.wikipedia.org/wiki/Not_invented_here) because I get to see it at play quite often. It is my nature to understand an environment before I start making changes but sometimes this analysis phase goes on too long. Here are the reasons I can think of to explain my reluctance to start coding:
- I don't want to add more technical debt on top of existing technical debt
- I am not keen to maintain code and have to answer questions from every Tom, Dick and Harry
- I think there is a smarter solution so I spend time writing half solutions then stopping halfway after realizing my solution will have shortcomings
Does anyone regularly go through these motions, if yes how do you overcome them? I realize there probably different ways to describe these emotions including procrastination, fear of failure but I genuinely love simple elegant solutions and when I feel there too making weak points in a system I get reluctant to jump in.
[Edit] formatting
36 comments
[ 453 ms ] story [ 4163 ms ] thread[1]: https://en.wikipedia.org/wiki/Analysis_paralysis
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.
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 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.
https://en.wikipedia.org/wiki/Not_invented_here
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.
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.
> [...] 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.
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.
"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.
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.
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 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)
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 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.
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.
The opposite of not invented here would be a company that refuses to develop anything internally.
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.