Dear Bob ...I happen to have something like your first example (in "Seven warning signs of bad architecture," Keep the Joint Running, June 5, 2006): two dissimilar systems that need data transferred from one to the other. I've written a program that reads the data in the one system, massages it, and puts it in the other, but because the two systems are so different in function and data formats, I always ha Dear Bob …I happen to have something like your first example (in “Seven warning signs of bad architecture,” Keep the Joint Running, June 5, 2006): two dissimilar systems that need data transferred from one to the other. I’ve written a program that reads the data in the one system, massages it, and puts it in the other, but because the two systems are so different in function and data formats, I always have to go back after the fact and fix what the automatic system couldn’t handle. So what is the proper way to deal with a kludge like that? I’d like to say that we should just have one system, but unfortunately, we haven’t found one system that handles the two different functions of our two existing systems. I could refactor my code and make it better, but I KNOW that some of the data transfer is something that only a human intelligence can handle (or else, I KNOW that I’m not a good enough programmer to write that intelligence.) What other options are there? – KludgingDear Kludging …While they’re generally pricey, you might want to look into one of the commercial ETL (extract, transform and load) software packages. It’s what they’re for, and you might find they’re able to handle some of the tricky cases that currently require human intervention. Either way, you’re probably handling this as well is possible: Automatically handle what computers can do, and kick out an exception list so humans can intervene where the computers can’t handle the situation. To me, this isn’t a kludge – it’s SOP.– Bob Technology Industry