The State of Code Integration?

Don’t forget: Integration is not free. #Android #Dev #F5

Many things are intended to work together, but require specific knowledge to get the outcome you desire. Automobiles and trailers, for example, require a trailer hitch, and not just any trailer hitch, but one with a ball the correct size to work with the trailer, and wire connectors that will plug in. It’s all in the interface, but once you have the knowledge and get it all hooked up, you can haul a lot more with the combination than with the vehicle alone.

There are, of course, many similar examples in the world, and ours is somewhat rudimentary, but does get the point across. Integration can make things more useful, powerful, cut the time required to do tasks… But requires knowledge. And that knowledge comes with a cost in terms of time. The more complex the problem, the greater the time cost.

In IT we have the tendency to look for the “easy” solution to problems. We want to deliver quickly, we want to include the bells-n-whistles, and we want to use what others have done to achieve these goals. Generally speaking, this is a good plan, but it has to be included in the project plan.

As many of you know, I’ve been spending my evenings working on an application for Android that has a ton of geeky details, like SSL connectivity and SOAP communications. Of course there’s no reason I would invent this stuff from scratch when some very smart people have already solved the problem, but it is not as if you can drop a library into a project and have it “just work” until you understand how it works to integrate it. Twice I have been asked to make this project an official F5 project, and I have said no, simply because the goal was to learn more about Android programming and I didn’t want that interfered with. The app is coming along, but there was the inevitable learning cycle. I’ve used both SSL and kSOAP (my chosen library for SOAP communication/parsing on both Android and Blackberry) before, but not in an Android environment, and both were several years ago. Both work differently on Android, and cost me 20 or 40 hours of work to get integrated with the server the way I wanted.

Losing a week on a project is not generally a good way to go. In my case there were no deadlines, and I was taking my time, making certain I understood the tools used for integration and the environment at a far deeper level than is needed for day-to-day development. In your case, include the time in project estimates. Something like kSOAP would take a far larger amount of time than a week to implement from scratch, so marking a week in the project plan is not that big a deal. Of course you have to meet deadlines, but you also have to be realistic. Integration does not happen on its own, and if you miss this stuff in the project plan, your project will be late. Why start out with that on your shoulders?

And assume that “interoperable” isn’t going to be so simple. IT is full of things that are supposed to work together (because they follow the same standards, for example) and don’t. It will cost you time to make them play nice, make sure you’ve got some set aside in that project plan.

Integration is generally easier than doing it yourself (imagine implementing Oracle from scratch…), but it doesn’t come for free – like everything else, that bullet ain’t silver – so make sure you give yourself the time to get things working without missing your deadlines.

And yes, I’ll be submitting change suggestions (again) to kSOAP, since some of the integration problems were solved by modifying core kSOAP code just a little bit.

Enjoy learning the new stuff, give yourself the time, and keep kicking rear. The mind boggling number of apps out there says we’re pretty good at what we do, just need some planning to manage expectations.