I hate the year combo box.  Yeah.  I said it.  Are we really so afraid that a user won't type in a proper 4 digit year that we need this thing?

Look at any online registration or purchasing form.  You need to enter a year for your date of birth, or your credit card expiration.  Easily 8 times out of 10 this is done via a combo box with prefilled years.  This, in and of itself, causes unecessary problems in design, maintainability, and usability.  This is an anti-pattern.

Design Problem:  Rather than be agnostic about the fact that you have to store a year, which is just an int (for most practical purposes), and not "special" data, you now have to understand the purpose of your input field.  Is it for date of birth?  When you prefill this list, how old are you going to let somene be?  What's your cutoff year?  Is someone born in 1901 really going to be registering for your site?  What happens if they do and you didn't include it?  What about a credit card?  How far ahead do you want to constrain those expiration dates?  What's the furthest into the future a card I hold now can possibly expire?  Better question:  why the hell would I even care?  Why would I waste valuable brain cycles trying to find out, and then storage committing it to memory?  Bottom line: Don't invite unimportant design decisions and constraints into your software.  Don't we have enough to worry about when putting an application together?

Maintenance Problem:  This one is pretty obvious.  By creating the Year Combo we have added a layer of maintenance to our UI that is totally unecessary.  Next year you have to add another year to your birthdate control.  Next year you have to remove this year from your credit card expiration control.  You have to do this at midnight on Jan 1 if it's a website otherwise you run the risk of errors in processing.  At midnight on Jan 1 you are supposed to be completely drunk and kissing some hot girl.  Not editing HTML or recompiling your application.  Sure, you could populate the box via code, with logic to choose the right years dynamically, but this requires a) that you have defined that requirement as described above, and 2) that you add, at bare minumum, 4 or 5 lines of unecessary code to your application.  Why would you do that?  Bottom line:  Don't design software that requires additional maintenance as a function of the design of the software, and don't design software that requires useless code to do that maintenance automagically.

Usability Problem:  This is the one that really irks me.  We are software developers.  Ostensibly, we are pretty sharp on the keyboard.  Is there anything more frustrating than tab-flying through a registration form then having to stop and use the mouse to pick a year?  Or take a year to pick a year by scrolling through with the keyboard?  Users expect to be able to type in these fields.  Autocompleting combos work pretty well, but on the web these aren't implemented widely.  They typically just suggest based on the first digit entered, which...well, when you're looking for 1977 in the list that ranges from 1920 to 2007, it's not exactly highly usable.  I know.  You want a 4 digit year.  You want to make sure it's numbers.  Solve that with validation.  Validation is so easy to do, and so much less intrusive.  99% of your users are going to type 1977 in that box.  The one jackass that types "I like cheese" is going to be greeted with a nice little warning about how a valid 4 digit year is expected.  Couple validation with a label that says "Year (4 digit)" and you can trust that your data integrity here is pretty much solid, and you don't have to create a usability hassle to do it.  Bottom line:  Don't hinder usability in the name of constraining data.

"Makes perfect sense Scott" says you.  "Why then, do I still see so many year combos?" says I.  "*shrug*" says you.  Yeah.

Phone numbers/Social Security numbers and other "formatted" numbers are another big complaint in this arena.  How many times have you filled out a form where the phone/social input was 3 boxes?  How about when you put it in there and it got kicked back by validation looking for a specific format?  This is all unecessary, and presents the same sets of problems in design and usability.  It's so easy to validate that an input string is a valid format for phone/social, why constrain the UI on input format?  I want to just type numbers man, I don't want to do dashes and parens and dots and hit tab a hundred extra times because you have decided it would be better to just break this piece of data out into 40 different input boxes.  The goal here is to make sure you get the data you need, formatting is not a concern of data.  They are separate.  That's why XSLT exists.  Data is separate from markup.  Handle it on your own, on the back-end, and don't be intrusive about it to the user.

I think there's an epidemic of not understanding the difference between the need to constrain data via the UI and the need to constrain data via other means, such as validation.  The Year Combo is my target as a big disgusting visible symptom, but the disease is deeper, much deeper.  Meanwhile, I continue to get pissed off about web registration forms.  /sigh.