7 ms·

Ask HN: Opposite of not invented here?

• mindcrime 10y ago
  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 https://en.wikipedia.org/wiki/Analysis_paralysis
• no_protocol 10y ago
  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.
  • mmsimanga 10y ago
    Thanks for the advice.
• valbaca 10y ago
  "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.
  • jrs235 10y ago
    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 http://amzn.to/2dyrWcM ) to be very eye opening and helpful in overcoming perfectionism.
  • mmsimanga 10y ago
    You comment does strike a cord with me. At the end of the day it is about shipping code.
    • brianwawok 10y ago
      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.
      • namenotrequired 10y ago
        My favourite cases are those where that problem is solved by removing code.
        • brianwawok 10y ago
          I feel so proud of - line pull requests. Especially if I added a test too.
• rubiquity 10y ago
  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.
  • dasmoth 10y ago
    For the organisational form, I've heard "never invent here."
    • endophage 10y ago
      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 https://en.wikipedia.org/wiki/Not_invented_here
      • dasmoth 10y ago
        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.
  • ismail 10y ago
    What would be the choice/dividing line on what to build vs rent(saas)/buy?
    • SimonPStevens 10y ago
      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.
• romanhn 10y ago
  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
  • mmsimanga 10y ago
    Thanks, I like the idea of setting a rigid time frame for analysis.
  • Mz 10y ago
    "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.
• blt 10y ago
  > 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.
• aristus 10y ago
  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.
• brianm 10y ago
  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)
• gwbas1c 10y ago
  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.
• ajeet_dhaliwal 10y ago
  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.
• geebee 10y ago
  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.
  • mmsimanga 10y ago
    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.
    • phhlho 10y ago
      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.
• pjlegato 10y ago
  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.
  • tracker1 10y ago
    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.
  • mmsimanga 10y ago
    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.
    • pjlegato 10y ago
      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.
• deleted 10y ago
  [deleted]
• kazinator 10y ago
  Prior related discussion: https://news.ycombinator.com/item?id=9112885 https://news.ycombinator.com/item?id=9112885