gaming, xbox comments edit

I blogged a while ago (in my drum comparison entry) that I’d never gotten 100% on a song playing the drums in Rock Band, even on easy difficulty, and I generally play on medium or hard. It was like my own personal Curse of the Bambino going on - no matter what I did, I’d always miss one note. Maybe it was a stupid mistake on my part, maybe it was a double-hit registered, but whatever the reason, never did I get 100%.

The curse has been broken!

100% on Hella
Good

Last night I got 100% on the No Doubt song “Hella Good” on medium difficulty. Interestingly enough, I actually got two 100% songs last night - the other was “My Best Friend’s Girl” by The Cars. The hardest songs in the world? Not by a long shot, but I’m still pretty proud. I’m not afraid to admit I was singing songs about how I’m the King of Drums last night. No, I’m not an awesome drummer, but I was pretty stoked with myself.

And, yes, you’ll see my character’s name is “Alyss.” All of my characters are named based on Frank Beddor’s Looking Glass Wars characters. My guitarist is Hatter Madigan, my band is Wonderland’s Millinery… you get the idea. Here’s Alyss:

Alyss from Wonderland's
Millinery

Coach Hines is a character on MadTV that teaches at a high school for boys. He’s one of my favorite characters on the show. Anyway, I was working on some fairly convoluted process stuff the other day and it reminded me of the choreography from his version of Oliver Twist:

General Ramblings comments edit

I generally don’t make plans to hang out with people during the week. It’s not that I don’t like visiting friends, it’s just that things never seem to quite work out. Folks are rushed getting off work, usually have to take care of some things at home, and you don’t really want to be out too terribly late on a “school night” because you do have to make it to work the next day.

Of course, sometimes I forget and we try. Last night was one of these times.

Earlier this week we got called by the local comedy club offering tickets to the Thursday night show. It sounded like fun, and we hadn’t been out with friends for a while, so we accepted. The show started at 8pm Thursday, but you had to pick up your tickets between 6pm and 7:15pm. No problem, right?

The first issue we ran into was that almost everyone else has adopted the same no-weeknight-events policy we have, so of the 8+ people we invited, two were able to make it. That’s OK, though, because they’re really good friends and fun to hang out with, so we weren’t really sweating the fact it wasn’t as big as we hoped. (It turns out it’s probably a good thing it was small.) As long as we could pick one of them up at home on the way, the other would meet us at the club and all would be well.

The second issue was that Jenn had a chiropractor appointment at 6pm on Thursday. “Don’t worry,” she said, “the chiropractor is really fast and if I’m there early, he always takes me early. I’ll just get there early.” I wasn’t terribly convinced, but hey, if she says she can make it, I’ll believe it.

Here’s how it turned out:

Jenn got out of work a half hour later than she usually does because it got busy. She noticed that her driver’s side headlight might be out and sent me a text message as such. No big deal. Anyway, getting out late put her behind a bit so she couldn’t quite get to the chiropractor as early as she hoped.

The chiropractor had a backlog of people hanging out in the lobby when Jenn arrived, so there was no way she was going to get taken care of early, and may be a few minutes late. It was at this point I was getting worried because I started doing the math:

  • 10 minutes for Jenn to come home from the chiropractor and pick me up.
  • 10 minutes to go pick up one of our friends.
  • 20 minutes to make it downtown in medium traffic.
  • 5 minutes to park if we’re lucky.

So as long as Jenn could leave by 6:30p, we could still barely make it in time to get the tickets. Close, but not a big problem. Plus, since I was sitting at home waiting, it’d give me more Fallout 3 time. I sent a message to our friend to let her know we’d pick her up a little later than we expected, but we’d still make it.

About 6:15p Jenn calls to say she’s locked herself out of the car. Remember that text message earlier about the driver’s side headlight? She turned the car battery on (power on, but not the engine), which locks the car doors, then got out of the car to see if the headlight was out. While she was out “knocking on the headlight” (no, I don’t know what the knocking was for), the car door shut. Locked out. Now I’ve got to bring her the spare keys.

We’re a little behind where I was hoping to be, but we’re still looking OK.

  • 5 minutes to get my shoes on, find the spare key, and leave.
  • 10 minutes for me to take Jenn the spare key and unlock the car.
  • 10 minutes to go get our friend and leave my car at their house.
  • 20 minutes to make it downtown in medium traffic.
  • 5 minutes to park if we’re lucky.

It’s about 6:15p, and with the 50 minutes it’s going to take to get things together, we have a 10 minute window (between 7:05p and 7:15p) where we can still pick up the tickets. Tight.

I make it to Jenn in the expected amount of time, unlock the car, and we both hop in and get ready to go. I say “get ready” because Jenn’s battery is dead and she needs a jumpstart. Now I know we’re not going to make it.

  • 15 minutes to push Jenn’s car to a spot where I can get to it, move my car, give the jump start, and put everything away.
  • 10 minutes to go get our friend and leave my car at their house.
  • 20 minutes to make it downtown in medium traffic.
  • 5 minutes to park if we’re lucky.

It’s about 6:30p and we won’t make it to the ticket booth until 7:20p, and that’s if everything goes right.

“Hey, Jenn, should we just call this off?”

“No, we can make it.”

No, we can’t. I love Jenn to death, but she doesn’t listen to me in situations like this, and she knows it, so it’s best just to go with it, as frustrating as it is. “OK, well, while I’m getting my car moved and getting the jump start going, let our friend know that we’re going to be even later.”

“I don’t have her phone number.”

Now I’m I/O-bound - I’m the only one that can get the cars set up for the jump start,and I’m the only one that can coordinate this whole thing. Does a text message or a call really take that long? No, but when minutes are literally counting, it adds up.

I got Jenn started, we put things away, and we headed off to our friend’s house. I, of course, hit literally every stupid stop light on the way there, so a 10 minute trip took closer to 15 minutes. (Thanks, City of Hillsboro, for having every light be pressure-sensitive instead of timed.) I called Jenn about halfway there to let her know this wasn’t going to happen. By the time I got there, Jenn had already told our friend and we decided to make the best of it and at least get some dinner.

Dinner was good, and it was nice to see our friends, so it all worked out for the most part. Makes me wonder if we shouldn’t have just gone for the smaller plans - just dinner - to begin with. Maybe next time. If there’s a next time. Maybe we should just wait until the weekend like we always do so it won’t go so horribly wrong.

GeekSpeak comments edit

One of the mantras of agile software development is “Release Early, Release Often” - every time you have a new, working version with fixes and updates, you should put that in the hands of the consumer. It’s a great idea - if there’s something new the consumer of your product, be they developers or otherwise, could use, make it available.

The problem lies in the reciprocal expectation of the producers of said product that the consumers will instantly be able to take the latest available version.This isn’t always a valid expectation and can get in the way of product support.

The happy-path scenario is something like a web application that is deployed in a central location and is consumed by various users. A new version of the web app becomes available, the service host deploys the new version, and the end users immediately have the new features and fixes available to them. When the customers need support, it’s pretty safe to assume they’re on the latest version.

What happens if the product isn’t like that, though? What if it’s a framework component like a logging library? In my experience, there’s a little more work required as a consumer of a third-party framework component to take the latest version than just “download and go.” It might look that way to the folks providing that component, but in larger environments that take third-party components on as dependencies, for every new version that comes out you have to consider:

  • Has the licensing changed? (If so, do we need to run this by Legal to get approval for the upgrade?)
  • Is there any fee associated with taking the upgrade?
  • What are the breaking changes?
  • What got fixed?
  • Were we inadvertently assuming incorrect behavior that has changed?
  • Were we working around incorrect behavior that’s now rectified?
  • For .NET dependencies, if it’s strongly-named and not installed into the GAC, do we need to add binding redirects to configuration? If so, where?
  • Does the product need to be installed on each developer machine or is it a dependency that can be checked in to the central source code repository and seamlessly updated?
  • If we have to support developers working on different versions of our product at the same time and each of our product versions relies on different versions of the dependencies, how does this change the manner in which developers switch their envrionments from version to version?

…and so on. Just because a new version is out doesn’t mean your customer can take it. I, as a customer, have to budget time in the schedule for investigating all of the above, testing the upgrade on a standalone developer system, performing any code changes required to take the upgrade, and synchronizing any updates to the developer environments.

So “release early, release often” doesn’t help me much in this scenario, and contacting your support department to ask questions about version 1.2 and you not helping me because the first line of support is to “update to version 1.3 and see if the issue is fixed” is crap. (I understand this line more from open-source/freeware projects than I do if I paid a licensing fee and expect support.)

My message to the “Release Early, Release Often” folks: Remember who your end users are. It’s great that you’re getting the latest version out as often as possible, but it may not be feasible for your customers to take what you’re dishing out as soon as it’s available.