Soft­ware com­po­nents should be com­pletely inde­pen­dent, with no (exter­nally vis­i­ble) state, no implicit links to other com­po­nents besides the spec­i­fied depen­den­cies. But soft­ware sys­tems may be sur­pris­ingly frag­ile when it comes down to mix­ing com­po­nents into an instal­la­tion of the prod­uct. This is no prob­lem for prod­ucts with “sta­tic” release poli­cies, where every instal­la­tion is the same. But this fragility is highly vis­i­ble in plu­gin envi­ron­ments like Eclipse, where every user tai­lors the instal­la­tion directly to his needs.

The Eclipse core acts as a frame­work, where plu­gin soft­ware may con­nect at spe­cific points and add its own func­tion­al­ity and exten­sion points. In my expe­ri­ence, updates to the eclipse core are treated with much cau­tion, at best — because “every­thing breaks”. So, why does every­thing break? Every func­tion­al­ity pro­vided by Eclipse is com­ing from plu­g­ins. Although these plu­g­ins are loosely cou­pled and inde­pen­dent, they rely on each other adher­ing the spec­i­fi­ca­tions of the role they fill. Slight changes in the behav­iour of one plu­gin may have a small local impact, but can affect the whole soft­ware sys­tem. Depen­dent plu­g­ins may fail, leav­ing exten­sion points unoc­cu­pied, which causes other plu­g­ins to fail.

This is only one of the pos­si­bilites of errors rip­pling through a whole sys­tem of loosely cou­pled com­po­nents. It is not easy to avoid those errors — test­ing all pos­si­ble com­bi­na­tions is rarely fea­si­ble, espe­cially if the pos­si­ble com­bi­na­tions of com­po­nents is very large and may not even be known to the com­po­nent devel­op­ers. There is no way a com­po­nent devel­oper can test all inter­op­er­abil­ity issues in such an envi­ron­ment. It is often hard enough to cor­ner the prob­lems local to his own component.

The ques­tion I think about at the moment is: Is it pos­si­ble to work with facts gath­ered from local tests and trans­form them into infor­ma­tion about an envi­ron­ment com­posed of pre-tested com­po­nents? In gen­eral, the answer is prob­a­bly  (and sadly) “no”. But maybe it is pos­si­ble to help users tai­lor their soft­ware instal­la­tion and choose only safe and com­pat­i­ble com­po­nents, per­haps by lim­it­ing the pos­si­b­li­ties down to com­po­nents whose tests are good for the same envi­ron­ments or tech­niques like “lazy tests”, which are only run when a spe­cific envi­ron­ment should be installed and test this com­bined envi­ron­ment for local errors.

This may enable soft con­straints on the installed envi­ron­ments, where neg­a­tive results are defin­i­tive (“this com­bi­na­tion of com­po­nents won’t work for this com­po­nent”), but pos­i­tive results have no real infor­ma­tion at all (“may fail in an untested case”).