Comments on Dependence Day: The Power and Peril of Third-Party Solutions

10 Reader Comments

Back to the Article
  1. Great article, very sound advice. I’ve been a junior developer in this situation a few times, but with no say on which way the client goes.

    I can really relate to that feeling of not being able to articulate why we should go in one direction or the other.

    Copy & paste the code below to embed this comment.
  2. From my experience I can say only that third-party components come in very handy when we are talking about stuff like D3 and/or NVD3. These kind of libraries take years to develop and include a lot of specific knowledge.

    At that point these are the only ones we are using as third-party components, and we got to them after initially tried to develop software that draws chart and tables in canvas by ourselves.

    Time has proven that DYI libraries/components/classes or however you want to call them in the context of your application and programming language, is far better. Even a few lines of commented code on specific places can clear up a lot of confusion and experienced developers rarely struggle with understanding and maintaining them.

    On the subject of scale-ability and customization, in-house developed code is better; given that there is sound architecture behind it and it’s not developed solely by an intern.

    Bottom line, if you have skilled people in the team who know what and how to do it, you are better off with DYI solutions for most of the cases. Long-term that is the only solution proven effective in our company’s field*.


    *Sports betting and gambling software.

    Copy & paste the code below to embed this comment.
  3. One other advantage to developing in-house is less bloat. Third-party libraries have all sorts of stuff you’ll never need. This is less the case with JavaScript, where developers are more careful about code size. But it’s also more dangerous, because the DOM has global scope and CSS rules often have unintended consequences.

    The flip side of this, of course, is the third-party libraries often have features you’ll ultimately need, that you’ll get before you need them.

    Copy & paste the code below to embed this comment.
  4. Great article.

    As the lone developer at a small creative agency, I’m faced with decisions involving third-party libraries or apps all the time. Often, it’s about saving time but also about solving problems that are over my head.

    But I’ve also been on the management side, making calls about whether we stay in-house or look outside for a given solution. I usually erred on the side of in-house for critical pieces of development, often citing the employees’ experience gained as part of my decision.

    I cannot stress enough how important code review and documentation are for in-house development. My first experience with team management involved an employee leaving under bad circumstances two months into my tenure, only for me to discover how little he documented code for business-critical applications.

    Copy & paste the code below to embed this comment.
  5. Great article and an interesting checklist.
    From a UX prospective, libraries make customization of a component extremely difficult. I’ve watched requirement watered down in order to support Dev teams “its good enough” mentality. Component breed laziness, and very few internal teams ever stand up and say “wow, I’d really like to learn something new.” Product management sees a deliverable met, and without concern for how the user will engage the system. The UX teams, revolt because the watered down requirement + component don’t support the full end goal.  In the end, higher calls to Customer Service because ‘its good enough’ wasn’t good enough for the user, and half the teams half quit from either boredom or annoyance. Components are built by developers and developers aren’t focused on providing the best user experience.

    Copy & paste the code below to embed this comment.
  6. Really interesting article. There are so many pros and cons to using third party solutions and I think you summarised them nicely. 

    Support is probably the biggest issue that needs considering, if a plugin or service doesn’t have a good community or support service then I probably wont use it.

    Copy & paste the code below to embed this comment.
  7. Interesting article. I find the easiest way to avoid the ambivalent nature of 3rd party applications is to speak to people. I use the community around any application to get an idea of how I may fare If I use the code. Through my work at boxChilli I have created a network of individuals who I can approach to discuss the potential dangers of using specific 3rd party applications before going ahead and wishing I hadn’t (which has happened to many of us I am sure).

    Copy & paste the code below to embed this comment.
  8. Nice article. A lot of projects are dependent on third party developments which has its own pros and cons. For searching a right solution provider or specifically a CMS development company, it is important to understand the business requirements and identify the key concerned areas. As there are number of players into enterprise content management, launch a search for the one which can fulfill the business needs and suits the processes that business follows. Select a platform that is secured, flexible and user friendly. Better if it can be used through mobile devices. For large businesses, it is advisable to have a CMS that supports multiple website in various languages.
    It is always better to plan out the requirements and search the most efficient and reliable third party solution.

    Copy & paste the code below to embed this comment.
  9. what a very interesting article you write…

    rideshare

     

    Copy & paste the code below to embed this comment.
  10. Sorry, commenting is closed on this article.