Saturday, December 22, 2012

Integration and Degradation

Software projects start modestly enough — a general problem statement that we've set out to solve. But then they grow. And grow. Either the problem changes, or our initial assumptions about how to solve it were so flawed that we just that far off in guessing how difficult the problem actually was. How prepared we were with our existing domain knowledge. How difficult it would be to acquire people with the right skills. Its in these situations that we take a software project, experiencing a deficiency of some sort, and start integrating other software components. It is through this exercise of integration that we're introducing unintended consequences of bringing on new software components.

Logically, it would make sense that we not re-invent the wheel in order to fill a gap in our system. There is likely something already out there, close enough to what you're missing that it would be silly not to try and utilize it. The alternative means building it yourself. Which isn't always a bad choice considering the fact that you're not integrating something specifically designed to fit your problem. Of course not, no. They software anyone integrates was designed for some other, possibly similar, purpose other than your own. With that in mind, the component you're integrating probably comes with stuff you don't want or need. Is it worth integrating, or do we have we convinced ourselves that the software meshes so well with ours that we need to invent ways to justify their interaction.

I would consider it rare, that a software company would integrate into their own software that they've devoted so much of their effort on, something foreign just for the sake of expanding the set of features. Of course, this isn't as straightforward a justification as it seems — there are political motivations, and so on. But peaking purely from a software level, the idea is to generate something solid for your customers on a predictable schedule. You don't do that by increasing the complexity of your code. You don't make your customers happy with features they can find in another product. Integration, for the safe of it, is usually a mistake. But integration for a specific enhancement could work, if carefully executed.

The key is in not including the unnecessary byproducts of the integration. Otherwise, you start facing the harsh reality of managing a graceful degradation scenario around every corner, and no software development team wants that on their plate. Instead of starting off with the right idea of fixing a deficiency, then jumping to new features where we end up complicating the entire system, focus fixing existing problems. Don't introduce new features as a side-effect of integrations.

No comments :

Post a Comment