Warning to software developers: Using third-party components during development may be hazardous to your product’s health.
According to the Arlington, Mass.-based Cutter Business Technology Council, using component-based technologies is an obvious time saver, but lurking within those mysterious components may be glitches that could adversely affect software reliability. And, as a recent survey by the Cutter Consortium reveals, over three-quarters of companies polled (80 per cent) are developing applications using third-party components.
The June 2001 study suggests that today’s software developers are addicted to the convenience of integrating third-party components obtained via the Internet or elsewhere, said James Bach, an associate with the Cutter Business Technology Council. But most developers, Bach said, are unaware of what’s embedded inside those components.
This means that developers might find it difficult to fix any problems that might plague their code, Bach said, which ultimately sets a limit to the reliability of most software. This limit gets lower and lower with each industry expo, he added.
“If you get just binary (executable) components, such as COM DLLs, you don’t really know what’s in them. You are trusting that they are doing what they are supposed to do, and nothing else,” said Jonathan Eunice, principal analyst and IT advisor for Illuminata Inc. in Nashua, N.H. “Since you’re installing them behind the firewall, and potentially in critical applications, they have an opportunity to corrupt your data or otherwise be mischievous.”
Despite what the open-source community likes to believe, Eunice warns that even having the available source code will not necessarily root out back-door or Trojan Horse-type security glitches.
“Even if you get the source code, do you really have the time and energy to scan through them to determine whether they’re making mischief or not?” Eunice said. “A component strategy ensures modularity, but it doesn’t guarantee that all the parts that you assemble will work together harmoniously. Integration and qualification are still essential.”
The Council suggests certain measures to determine if components are a net benefit or a net liability. Companies should first analyze their defect tracking system, and tally the number of system problems deemed to be component-related. It also advises companies to look closely at ‘schedule slippage’ – developmental delays caused by integrating components with the code.
The Council believes that companies should poll their developers to see which components work and which don’t – taking into consideration that the developer who decided to use the component might not want to tell you that it doesn’t work well and now the entire architecture of the product has to be changed.
All things considered, the potential benefits of components do outweigh any potential dangers, Bach said, and in some projects it would be negligent not to use a component-based technology.
“Whenever you buy external software (components, middleware, applications), you entertain some security and performance risks. The same thing is true when you have developers (your own or contractors) build a similar function for you. Almost always, the cost and complexity of do-it-yourself dominates the discussion,” Eunice said.
He maintains that third-party components are not any more dangerous – nor any less dangerous – than any third-party software. He insisted that due diligence is needed with external software and vendors must verify if they’re dealing with a reputable supplier and a quality product. Talking with others who’ve used the product, he said, goes a long way in ensuring you don’t get burned.
“It’s all about trust. You shouldn’t trust just everyone, but there’s no special danger in buying external components, (especially) given the economics of software development,” Eunice said.
“No one can afford to write everything themselves from scratch.”
