iTunes 8 – Thanks but No Thanks

Leave a reply

I fired up iTunes this morning and received a message asking if I wanted to upgrade to iTunes 8.  Ever since, oh iTunes 7.2, I’ve always clicked no and then done some additional research to see if anything in this update would break my system. Some would say that’s just due diligence, but I think it’s becoming a serious problem.

In all honesty, I really shouldn’t have to be distrustful of getting software updates.  Sure, upgrading major releases, like from iTunes 7.x to iTunes 8, may warrant some additional research. But what about minor patches?

I’m definitely started to lose faith in Apple’s iTunes sofware, and here’s why:

  • Lack of transparency: Have you ever tried to search for iTunes release notes? Here, try it. It’s always strange that Apple’s own web site is never top of the list (or anywhere that I can see it).  But even when I find some sort of release notes, they are vague at best.  “Fixes to improve stability and performance” seems to be the cut-and-paste phrase for every release.  That’s great, but what does that mean exactly?
  • Lack of Disclosure: Ed Bott’s arcticle from ZDNet gives a pretty solid example of this. In it, he talks about all of the “extras” that iTunes secretly includes in its software updates.  MobileMe anyone?  Yea, that might be useful if I owned an iPhone/iPod Touch and wanted to use that service. But I don’t… and I don’t.  So why should I have to install it on my computer?  Unfortunately, that software sneaked onto my computer with the iTunes 7.7 update and it didn’t come with a way to uninstall it (and I haven’t yet found a way that the internet community can agree works without also breaking anything else). Though it sounds like iTunes 8 does allow you to uninstall the MobileMe software… but maybe it’s just a trick to get other software on my computer… (lack of trust, anyone??)
  • Lack of Trust in Quality: Ed’s arcticle also points out the gap in QA that Apple has on the WIndows side.  It’s been a while since I’ve seen the BSOD and I’m leery of any software that would potential raise this issue.

All in all, Apple really needs to shore up its efforts in the software that it pushes out to people.  Otherwise, it’s going to start seeing people jumping off the iTunes bandwagon. After all, it’s not the only fish in the sea anymore.

MSDN Article on Object Design

Leave a reply

This month’s MSDN Magazine has a pretty interesting article on Object Role Stereotypes.  The article reminded me of the GRASP design patterns that I learned back in college.

The article also mentions the value of using CRC cards as a design exercise.  This is another practices that I’ve heard about, but have not had a chance to experience first hand.

All in all, a decent read if you’re interested in some conceptual knowledge around object-oriented design.

A Coder’s Challenge

Leave a reply

I was recently “challenged” by a fellow agile member who claimed that Java developers have a higher maturity level then their fellow .NET developers.  His claim was that .NET developers rely too much on the mouse when programming, which makes them slower because their hands have to leave the keyboard more frequently.  Java developers, on the other hand, are more familiar with their tool (e.g. IDE) and all the keyboard shortcuts that are programmed into it.

So, I considered his claims and his challenge.  I scoured the interwebs, searching for the knowledge I sought that would help me master the .NET coder’s tool of choice (the great Visual Studio), until I found what I was looking for.

And so, for my fellow .NET “adolescents”, I share with you this, straight from our god herself:

You threw down the gauntlet, B.C. and I accept your challenge.

Scott Ambler Presentation

Leave a reply

Scott Ambler was in town earlier this week to be a keynote speaker at the local BADD 2008 conference, and I was fortunate enough to attend a separate presentation on Thursday night at the West Des Moines Marriott, where Scott talked to around dozen of IT individuals about strategies for scaling agile development in real-world environments.

Overall, it was a great presentation. Scott has a reputation for speaking his mind about topics, and there was no shortage of that here. However, he is also known for making arguments based on factual material and he shared a number of research data with us around the adoption and success rates of agile (of which some of the data can be found here).

It definitely had a flavor of IBM Rational bias, but a lot of the messages were applicable beyond the scope of IBM and its RUP product to agile practices in general.

Overall, the message was clear: Agile is making (or has already made) its way into the mainstream, and it is going to be around for the long term.

The Definition of “Done”

Leave a reply

There is a good post over at the Agile Advice blog regarding Scrum’s definition of “done” and how to customize it to your own team environment.

This is something my team has been struggling with lately. We’ve been implementing a Kanban-like approach to managing our work items. For most of our work items, we have common activities that we need to accomplish, such as:

  • Holding peer design reviews
  • Writing unit tests
  • Filling out PCM requests (gotta love SOX)

However, we don’t keep a list of these activities out in the open which means we sometimes forget – or “forget” – to do a particular task.

By creating a checklist of tasks required to call a work item “done” and posting it in a visible location (like a wall), this helps keep everyone on the team honest and makes sure that no tasks are forgotten.

The Fallacy of Written Communication

Leave a reply

I recently stumbled upon a good post that Mike Cohn wrote a a while back on his blog about the problems that often arise from textual communication.

It is especially meaningful how he relates this, from a software development perspective, to requirements documentation and the impact it can have in that respect, as well as the day-to-day e-mail traffic that goes into and out of… mostly into… my Inbox.

I often find myself among the minority of developers who, instead of firing off an e-mail, opts to pick up the phone, or stop over for some face time with my fellow business users, business analysts or project managers. Perhaps that is the weakness of IT: brilliant (usually) at analytical and technical skills, but lackluster in social interaction skills…

Think back on the past week. How often have you opted to write an e-mail to a co-worker instead of pick up the phone or walked 10, 20, (or, god forbid, 50) feet to the person’s desk? Worse yet, how often have you been part of a conversation that took place entirely via e-mail. You know, the kind where a dozen (or more) people are included in the e-mail chain — 18 of which could care less about the discussion?

(I know I’ve brought that issue up once before…)

It is at times like these where I stand up, blow the virtual whistle (loudly) and suggest (strongly) that we schedule some face-time to hash out this discussion in person (or at least via conference call).

Now, think about what agile methodologies and practices propose to combat this issue…

Daily scrum meetings?

On-site / Nearby customers?

Manifestos?