thedailywtf
There's nothing quite like being told bluntly at a job that significant proportions of their code are royally screwed ten ways to Sunday because they previously hired someone who (a) couldn't program, and (b) decided to hide this fact by creating the most convoluted, spaghettified, fragile, bug-ridden code around.
For several years.
As an example of what I run into on a daily basis, there is a SQL function, one of many, which pulls certain corporate record data from their single great big mashup database for a given financial year. However, instead of taking a date range parameter, or a financial year in any known format, or even just a single date (and extrapolating the correct date range from there), it takes an integer. This integer is used as the key in a lookup table which matches it to start and end dates, which are then used as framing parameters in the SQL query.
Some points:
- The table is populated manually.
- It is only updated at the beginning of each financial year, instead of pre-populating it with a hundred or so entries.
- It can only be updated by the one database admin in the organisation, who usually has three million other tasks more important to do.
- It has no entries for before 2003, so the function can't be used to retrieve data from before that year.
- The first two entries in the table - #1 and #2 - are SWAPPED, so although the entries from #3 onwards are incremental, you can't just calculate the key based on the current year in case someone wants data from way back then.
And of course, the whole requirement for a table lookup just to convert a date range to a key integer and back to the same date range, but with a hiccup for two years only, is just NUTS.
So because the function can't be called any other way, and I don't have the access to alter the function (and no desire to rewrite it), I now use an in-FY date as a reverse double comparative index key against the dates held in that same table to look up the required integer, and then pass that integer back to the function itself.
I also feel slightly dirty.
For several years.
As an example of what I run into on a daily basis, there is a SQL function, one of many, which pulls certain corporate record data from their single great big mashup database for a given financial year. However, instead of taking a date range parameter, or a financial year in any known format, or even just a single date (and extrapolating the correct date range from there), it takes an integer. This integer is used as the key in a lookup table which matches it to start and end dates, which are then used as framing parameters in the SQL query.
Some points:
- The table is populated manually.
- It is only updated at the beginning of each financial year, instead of pre-populating it with a hundred or so entries.
- It can only be updated by the one database admin in the organisation, who usually has three million other tasks more important to do.
- It has no entries for before 2003, so the function can't be used to retrieve data from before that year.
- The first two entries in the table - #1 and #2 - are SWAPPED, so although the entries from #3 onwards are incremental, you can't just calculate the key based on the current year in case someone wants data from way back then.
And of course, the whole requirement for a table lookup just to convert a date range to a key integer and back to the same date range, but with a hiccup for two years only, is just NUTS.
So because the function can't be called any other way, and I don't have the access to alter the function (and no desire to rewrite it), I now use an in-FY date as a reverse double comparative index key against the dates held in that same table to look up the required integer, and then pass that integer back to the function itself.
I also feel slightly dirty.