One Easy Way to Improve the Quality of Third Party Components

Software products these day are increasingly made up of components from a variety of different sources.  These components provided by the open source community, supplier companies and software vendors provide functionality for user interface management, operating system access, security interaction, connections to device and more.  In addition, software developers also use code generation tools that enable developers to manage the application at a higher abstraction.

By using third party components, an application with much more functionality can be pieced together much more quickly than ever before.

Yet the customer who receives the product, be it a smartphone, router, medical device, software application certainly doesn't care how it's developed - only that it works.  Developers increasingly must be able to manage not just the code that they've written but also the code that they integrate into the overall solution.  Although it is in one sense, out of their sphere of control, they must manage the integration of the code so that the overall solution has the needed quality, security, performance, reliability and more that is expected of the finished product.  Managing the interfaces well in some cases is not enough -- many developers must opt to own the source code so that they can make the needed modifications to make it work for their needs.

We work with many companies who run into this situation.  They analyze source code using static analysis on their codebase to find all sorts of problems to fix.  In order for the source code analysis to work better, they also analyze the third party code that is bundled with their end product.  This is an important step because many bugs stem from the improper interaction of components - and without analyzing the whole program you either miss out on a lot of bugs or get an inordinate number of false positives depending upon the static analyzer's conservative or aggressive assumptions.  Clearly, defects that result from the direct interaction with these third party components should be fixed.  This is something within the control of developers.  Defects found in the source code of the third party code should also be fixed although many developers find themselves powerless to change the vendor's code or realize that they must increase their overhead by making changes to the source code and managing that change for future versions.  It's extra work.

But the developer has some leverage.  We have worked with many forward thinking companies who lean on their suppliers to do their own code analysis, and to fix up the problems.  For those companies with extra leverage, they have even demanded their suppliers to provide clean code as an acceptance criteria. These companies take a whole product view of the code, realizing that a bug in a third party component doesn't make a bit of difference to an end customer who's system or application is broken.

So if you do run an analysis and find problems in third party code, put the burden on the supplier to fix up their code.  It's very reasonable for a company to run a quick analysis and to put a concerted effort to fix the problems (although they will have to obtain their own license).  You may be surprised at how much leverage you have.  And demanding good, clean code is something in everyone's interest.  It will save you a significant amount of time downstream and more importantly provide the quality experience that your users expect.