Agile .NET Geek

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 internets, 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:

• Visual Basic 2005 Keyboard Shortcuts
• Visual C# 2005 Keyboard Shortcuts

• Visual Basic 2008 Keyboard Shortcuts
• Visual C# 2008 Keyboard Shortcuts

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

• Comments (0)

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.

• Comments (0)

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.

• Comments (0)

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?

• Comments (0)

Mike Vizdos has a great cartoon / blog entry about the importance of IT understanding the business(es) that they support.

I must say that I was surprised by his take on who my real customers are (or should be). It definitely gave me pause about how I should go about developing solutions for my business users.

If nothing else, the article gets you thinking outside of the norm. How very… agile.

• Comments (1)