The Integration Engineer
When it just has to work.

Bugs are sometimes defined as when a program does anything that the user does not expect.  However sometimes users expect some unreasonable things.  So what is a bug?  Well I definitely think that it is more than when it does something that the programmer doesn’t expect.

In that vein, sometimes bugs can be when the program does things that the programmer did intend.

All applications have a primary purpose.  After that they have secondary purposes.  And then many times there are aspects of applications that start to get in the way of the primary purpose.  A good example of that can be found in a popular word processing application from Microsoft.  Taking advantage of this application’s auto-correction feature, people can create a situation where typing in a common word will auto-correct it so a word that is not intended by the writer.

When this happens we may all laugh, but a secondary feature of the application, (auto-correction), is preventing the primary purpose, (composition), from being accomplished.

There are times in software development, both in user applications, and in back end scripting, when leveraging a secondary feature, subverts the primary purpose.  When that primary purpose is a mission critical function, we can get that call in the middle of the night.

Or as I like to call them, “Disaster Recovery Dreams.”  Sure, you need to have a plan before you can test it.  But before you really tell customers, management, team members or even yourself that you have a Disaster Recovery Plan, you need to have it tested.  Until them you are dreaming.

All this does not mean that you test it once, and then leave it to age in the recesses of your file server.  This is a plan that needs to be reviewed periodically.  With every major release.  The parts of the disaster recovery plan like database restore activities need to be requested every few months to make sure that the tasks are repeatable and the backups are valid and ensure that a recovery is possible.

These periodic and onging tests and updates make sure that if you ever have to implement your plan, that you will be recovering to your current system, not to the system when the plan was created.

I know it may sound cleche to state that a picture is worth a thousand words.  But some things are just really difficult to communicate in text.  You may have noticed a few diagrams showing up in my posts here.  Well, I have found that there are times in a conversation with other programmers, and more often in conversations with non-technical collegues that I am saying, “I need a whiteboard.”

Because of this propensity to illustrate my explanations, people have jokingly said that I couldn’t talk if they took my dry erase markers away.  At the same time, being able to communicate with others that are not versed in programming, databases, chemestry, or any other disapline that you find yourself will be a useful skill that will help you with your immediate project, and can advance your career.

When the definition for a data field or element is undefined or otherwise open to the whim of the user, we are asking for trouble.  Not in the sense that this causes trouble.  But how it is then used that causes trouble.  And this is not to pick on the CDATA tag in XML or ZZ qualified elements in EDI.  It seems that every data format of any size of adoption commits this sin of categorisation.

My general recommendation is to avoid using undefined or user defined data.  Relying on a user defined field that we use to solve a problem by working around some limitation (or perceived limitation) of the file data definition, may give us a feeling of power.  But over the long haul turns the implementation into a proprietary implementation that is not reusable with more than one trading partner.

And having each integration using a slightly unique implementation leads to chaos.  Both in suppport, and in the applicaiton of updates.

Undefined data exists.  People will use it.  You will have to deal with it as some time, but whenever possible. avaid making it a critical part of the implementation, and always provide it with a healty dose of error handling.