I've always been amazed at the ability of the IT community to come up with new words on an almost daily basis. The thing that's really scary about it is that if you're truly geeky enough, you know what the new words mean without being told. The first time I remember this happening was about 18 years ago, at the first Sybase Conference I attended in San Francisco, and someone used the words 'legacy code'. I had never heard the word 'legacy' used to refer to anything having to do with technology, but I immediately knew what the reference meant. But then I fought it, and parts of my brain didn't want to accept that 'legacy' could refer to something that was only a few years out of date. My practical side ended up winning out, and I went along with the new meaning of 'legacy'.
In my most recent class in Portland, earlier this month, I was introduced to two new geek words, although one was really a phrase, not a single word.
The first is 'Technical Debt'. Doesn't that sound cool? And it's not referring to the price of a new 16 proc, x64 server. One student says the DBAs and data architects at her company use that term when talking to management about their decisions to go for the quick fix, instead of really looking at what caused a problem in the first place and addressing the underlying cause. The term is referring to the fact that the quick fix will usually end up costing more in the long run. One example might be a quick fix of using a query hint to force SQL Server to use a particular index, but as your data changes that hint is no longer the best choice. You accrue technical debt by choosing to use the hint instead of rewriting the code, or building better indexes, because eventually the hint will no longer give the best plan, and it will be even harder to track down and fix the bad performance with the hint in place.
The second word is 'misfeature'. I know if I thought long enough, I could come up with lots of examples of this. A misfeature is something we want to call a bug, but Microsoft calls a feature even though you know it is really WRONG. The immediate example that comes to mind for me is the dynamic management function sys.dm_db_index_physical_stats that requires a database ID as a parameter, and also requires an object_id. However, the object_id is evaluated based on your current database, not the database specified in the first parameter. You can get some very strange results if you are accessing this function from a different database that the one you are querying. I specifically mentioned this to one of the storage engine engineers at Microsoft, and was told it was a feature. To me, it is a MISfeature.
I'd love to hear examples of behaviors that put you in Technical Debt, or examples of your favorite misfeatures.
Thanks!
~Kalen