THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

Kalen Delaney

Geek City: New Geeky Words

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

Published Friday, November 30, 2007 1:11 PM by Kalen Delaney

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Pam said:

Most recent example of technical debt:

Company calls me in to fix a DB that has been running for about 2 years with no maintenance to speak of.  I tell them I need to take it offline for about 2 days to run all the fixes.  They balk (even though it is an internal DB used for reporting / analytics) so I come up with alternatives.  These alternatives, due to the state of the DB, wind up taking 3 + weeks to process through (and we're still not quite done).

November 30, 2007 3:53 PM
 

Kalen Delaney said:

Great, Pam! I would think just the fact of not running any maintenance is accruing loads of technical debt! So your case is like compounded interested on the debt.

~Kalen

November 30, 2007 4:11 PM
 

Hugo Kornelis said:

Hi Kalen,

For me, the premium example of a misfeature is the change in behaviour of @@PROCID that occured somewhere between SQL Server 4.2 and 6.5.

We were converting an existing DB that used @@PROCID in triggers to determine which stored proc executed the DML command that caused the trigger to fire. But on SQL Server 6.5, @@PROCID suddenly returned the object ID of the trigger itself, making the function completely useless for that purpose (and AFAICT, totaly useless at all). So we called MS and reported this as a bug.

We were later called back and told that this feature was working as designed. They also insited that this was not a change. So we pointed them to an example in BOL where the printed output demonstrated the old behavior.

Some time late, we were once more back again. MS then admitted that indeed, there was a bug ... in the documentation. @@PROCID has never been restored to it's 4.2 behavior and therefore remains as a completely useless function from the code museum.

November 30, 2007 4:43 PM
 

Pam said:

"I would think just the fact of not running any maintenance is accruing loads of technical debt! So your case is like compounded interested on the debt."

True.  I like to be kind and chalk that part up to ignorance, though.  Guess that comes from seeing the same thing (shop running SQL Server with little to no maintenance / administration) over and over.  Oh well, coming in and saving their backsides is what pays my bills so guess I can't complain too much.

November 30, 2007 4:51 PM
 

mbourgon said:

We get that all the time.  Fix the FTP script/sql code/batch file this one time and hope it never happens again, or fix the process while everyone else howls that you're not working on _their_ stuff...... so it gets the quick fix.  

And there's no such thing as a MISfeature - if it's documented, it's a feature, if it's not then it's a bug. We're just used to making quotes with our hands when we say "feature".  

November 30, 2007 5:19 PM
 

Kalen Delaney said:

Maybe there wasn't any such thing as MISfeature before, but there is now. After 20 years with SQL Server, I get to add new words to the lexicon.

Maybe the official definition of MISfeature could be 'feature for which you have to make quotes with your fingers when you talk about out loud'. However, I need a term to use when writing, not just talking.

Thanks for your input!

~Kalen

November 30, 2007 5:44 PM
 

Linchi Shea said:

Index fetish

November 30, 2007 10:44 PM
 

Kalen Delaney said:

Do I dare ask what exactly you are referring to?

:-)

~Kalen

December 1, 2007 12:49 AM
 

James Luetkehoelter said:

Hey, I had a couple of geeky words that I think I've coined - correcte me if I'm wrong:

Buzzronym (noun) Any acronym that takes on a meaning of its own simply due to its frequency of use (DR, BC, OLE DB :) )

Technedium (Noun) 1)Technical details contained in a speech or writing that enduce a proto-comatose state or 2) any "some assembly required" manual

December 1, 2007 8:22 PM
 

Tom Pullen said:

'Scope creep'. I love the way it sounds so sinister.

December 3, 2007 5:50 AM
 

John Clark said:

Maybe these are not misfeatures but special MSfeatures from our facorite database vendor..

December 3, 2007 2:50 PM
 

Kalen Delaney said:

Tom... you're right, it does sound sinister. Actually, I wasn't specifically asking for new terms, but for examples of the new terms I mentioned: technical debt and mis (or MS) features.  But I do like this one too... what your favorite example of scope creep?

Hey John ... I like that!

December 3, 2007 2:58 PM
 

Paul Nielsen said:

It's not SQL Server but my big MisFeature pet-peeve is the lack of Control-tab capability to switch between tabs in Excel. IE7 has it, Visual Studio has it. SQL Server Management Studio has it. If that's the standard keyboard method for toggling between tabs why doesn't Excel 2007 support it. Don't the Excel Program Managers use IE?

December 3, 2007 6:56 PM
 

Linchi Shea said:

Oh, not what you might think :-) I'm referring to the excessive and irrational devotion to creating more indexes in hope of solving query performance problems. In my observation, this is such a common approach that often accrues 'loads of technical debt'.

When you walk into a client, it's not uncomon to find a table with loads of indexes created over time. So, a new guy comes in to solve a performance problem, and finds a need to create a new index. But he is either too afraid of removing any other indexes already there in case they might be used somehow or he doesn't even take time to look into those indexes at all. He has a problem to solve and he solves it with his new index(es). Period. Done. Often, the guy doesn't look beyond his immediate problem to see what side effect his new index(es) may have as long as it doesn't have any immediately detectable adverse impact.

As an example, I know an application that has a transactionally replicated database. In the quest for better ad hoc reporting performance, more than 30 indexes have been created on a large table on the subscriber side over the course of the table's existence. And people are complaining about replication not meeting the throughput requirements.

December 4, 2007 9:12 AM
 

Adam Machanic said:

Tom: I much prefer "creeping featurism" :-)

December 4, 2007 10:38 AM
 

Kalen Delaney said:

Linchi -- Perfect!

I use this example all the times in my classes, but never related it to 'technical debt'.  I was brought in to troubleshoot a system with 'slow performance' where the main order entry table had 32 indexes! And that was on SQL 2000, and the only way to see which indexes were used was to capture a trace for half a day and then run Index Tuning Wizard.  (We found many indexes that could be combined and many that could be dropped, and ended up with 6.)

This is one of the reasons I love the new metadata and sys.dm_index_usage_stats is just about my favorite new feature in SQL 2005.

Since I charge by the hour, maybe I shouldn't love it so much, but I can't help myself. :-)

~Kalen

December 4, 2007 2:35 PM

Leave a Comment

(required) 
(required) 
Submit

This Blog

Syndication

Favorite Non-technical Sites or Blogs

Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement