When building software applications, code dependencies are an area worthy of your attention. One form of dependency is injected via third-party libraries. These dependencies include binary executables that perform tasks such as single sign on, event logging, UI widgets, middleware control and data manipulation. There has always been a tension between build versus buy. This occurs at all levels within a stack and organization. I am referring to software that your team is building and maintaining. It is extremely easy for someone to make a decision that “xyz” third-party library would save hours of design, development and testing time. The tool is downloaded and integrated into the developer’s local build. Depending on your process, it may make its way into your code repository and then, through automated deployment, into production. This is a problem. Make sure your processes do not allow new technologies to enter the SDLC without some level of governance.
Important considerations when managing code dependencies
This blog post focuses on the pre-meditated and managed injection of code dependencies. It is as much a philosophical discussion as it is a technological one. If you write 100% of all code inside your stack, you have 100% control over it. The dependencies that you create are your own. Security, versioning and source management all fall within the realm of your suite of tools and processes. With each new third- party library, you add a level of complexity and risk. In the short run, you may reduce engineering projects and decrease delivery schedules, ultimately bringing your product to market faster than if you built every line of code yourself. However, the price you pay will increase as you add more libraries. As you continue adding libraries, the matrix of complexity expands. If one day you find yourself with several million users banging on your code and a problem rears up, reaction times can become treacherous. The easiest platform to debug is one where there are no layers, one code base and no dependencies. In most cases, this is not, or cannot be the reality. Have your team build as much code as possible. Of course there are situations where a third-party product makes sense. Add it to your stack after giving serious consideration of its implications three years from now. Don't let tight timelines and limited budgets be your guide. Think about why you need to use a third- party library. What are the savings verse the long term cost of support. What happens if the library develops a security vulnerability? Do you need to report it to all of your customers? Is the vendor going to react as fast as you would if it were your code? What happens when a new version of the library is released? When the vendor decides to change the interface and you need to update code in order to remain on a supported version, then what? Third-party libraries can be a value added element of your technology strategy. Be thoughtful and always remember the old FRAM Oil Filter commercial. "Pay me now, or pay me later." Don't let your short term savings result in excessive long term expenses.