So my first submission is pretty meta, but it just has to be asked...
Have you ever come across some pretty aggressive code? Not code that is destructive, or buggy, or even poor performing, but rather where there is no explanation other than the developer had to specifically code a certain behaviour into the application? I'll share my latest encounter of this...
A colleague of mine had to create a SQL view of client data for another set of developers, who had prescribed the columns they wanted present in the view. Standard stuff. He wrote the view, and sent it to the other devs. During testing, it quickly came about that they needed to see what type of client each record represents. No big deal, there's a ClientType field, and my colleague offered to add it to the view.
Their response: "No. Don't add another column to the view. It will break our process."
"Process" being the hereto unknown jargon for "routine that consumes the view".
Really? Break the process? I can't help but think that this "process" includes code which:
- Queries the view (potentially a Select * From ClientView)
- Count the number of columns returned (Bonus points if it compares the names of the columns to what it expects)
- If the above yields a number different to the actual amount of columns it wants, then throw an exception.
The logic is sound for when too few columns are returned, but too many?!
So the workaround to this (based on the other dev's suggestion): Prepend the ClientId column's value with the Client Type. But not the integer value stored in the field. Nope, join to the lookup table and get the first character of the display value. I haven't even mentioned the fact that the ClientId is a Guid.
So in short, because they coded an aggressive routine in their application, we can't add an additional column, but we also now have to butcher a Guid to look something like P-29ADE5D6-3EEB-43AC-8D5A-0F0F3EFDCB7D
At this point, I am without words...