Someone asked me to add a cheap and nasty "import" facility to an existing product. I was told that the source was a MS Access database, "but this might change in the near future", and given the record structure, "but this isn't fixed; it might be extended".
I suggested that the import facility be implemented as a SQL query via an ODBC driver, to "future-proof" it; if the database changed, only a single parameter (the name and address of the database) would need to be changed, and changes to the record structure would not affect the SQL query (unless any of the fields were deleted). I told my bosses that my solution would take two days to code, test and implement. They said that this was too long. They insisted that I import a comma-separated variable (csv) text file exported from the database. I pointed out that this wasn't an automatic process; the operator had to perform at least one manual step, and changes to the database (which might cause the data to be exported in a different format) or record structure would require the import feature to be changed. They insisted I proceed with their preferred text file import, which would take me only a day.
Inevitably, within a week, an operator complained that the import process hadn't worked, and had filled a data file in the main product with gibberish. I investigated and found that the operator had concatenated three separate text files. The record layout had changed between each export, so there were three separate formats to deal with in the file. It took me three days to clean up the affected data, and manually import the horrid text file, writing three "off-the-cuff" import functions to do so.
I suggested again that I rewrite the import function as an SQL query. Management refused, again. Within a month, the import feature failed again for the same reason, the record layout having changed, and an inexperienced operator having mangled the export to text file procedure.