Rule #1 of deploying software: Expect it NOT to work!

I got to work this morning and after catching up on my reading I decided to check out some tunes on Zune Marketplace while I wrote up some documentation [I hate documenting stuff, but it's a necessary evil]. I fired up the Zune software, searched for Buckcherry [I'm on a kick with them right now] and lo-and-behold what did I see:

Where was my "download" option? I have a Zune Pass and should be able to download/stream 95+% of the music in the Marketplace. In fact, I was just listening to some of their stuff yesterday, so I know it's available and I can play it. WTF?

I checked my account settings and they looked fine. I went to Zune.net and there weren't any messages/warnings there. I finally went to an internal mail list and saw a thread titled "download option disabled with zune pass." Ah-ha, that looks familiar! Sure enough it directed me to Cesar Menendez's post from yesterday: Zune Marketplace: Down Between 2 and 5 AM PDT (Maintenance Only). But I'm sitting at my desk and it's about 9am PDT. A full four hours past the end of the maintenance timeframe. Oops.

So I have a few suggestions for the Zune group...

1. Expect it NOT to work! Let me repeat this...expect it NOT to work! This is very important when running a service! I have spent enough years in Operations [7+] to know that deployments almost NEVER go as planned. If you think it will take 3 hours in the middle of the night you better actually plan for 6 or 9 or even 12. Not only will it probably take longer than you anticipated, but it probably won't work at all the first time.  So you better have a rollback plan [how to get back to the previous version that worked] and a timeframe where you're going to give up and just shoot it in the head [scrap the new release and rollback].

2. Tell me what's going on! Give me a notice/message in the Zune application when I first sign in. "We're performing maintenance right now. You will not be able download/purchase new music." If that's not possible [which I know it is, but for argument's sake...] then at least put a nice broad message on the front page of Zune.net. How many Zune subscribers know about or even read ZuneInsider? A small percentage I'm sure. Don't get me wrong, it's great that Cesar mentioned this, but it's not the right venue for the only message.

After writing this post it's now 10:30am, I have my download buttons back and am listening to Buckcherry, but a little more planning would have made this a much friendlier consumer experience.

~tod

tags: zune, operations

I had a moment of clarity last night and came up with a software development analogy that really rung true for me. Maybe it's because we're 5 weeks into football season. More than likely it's because my group has gone through another re-org recently and we had our first all-hands meeting yesterday. [Quick aside: it's a joke around here that if you keep track of your managers and offices over your MSFT career you'll end up with a pretty long list ] In the all-hands meeting, our new director discussed wanting to unify the processes being used by the many development teams now in his group. More detail isn't really necessary, just suffice it to say that it started some conversations and got me thinking about development practices.

That's where football came in. I started thinking how the positions on and off the field correlate to the different roles in software development. Here's my take on it...

Assumptions. Every project or business plan should start with some explicitly stated assumptions/assertions so I'm going to do the same thing here. I am making the assertion that a single football game is equivalent to a single development project.

And the positions...

• Offense. This is the group that scores the points, or in the case of software gets the stuff produced and ready for consumption. In software development, making progress (milestones) on a project feels like scoring points and is what defines whether you've won the game or not. Collectively, a software development team's offense consists of the developers and PMs.
• Quarterback == Lead Developer
  • I'm going to start with the most coveted, popular, visible position on the field, the quarterback. The lead developer might not write a lot of code [score points], but they're constantly meeting with the various groups [huddles] to help guide the project.  They direct the developers' priorities and areas of focus within the project [calling plays], constantly re-evaluating the team's progress. Sometimes the lead dev will jump in and write some code like a quarterback that can't find an opening and runs the ball himself, but most of the time they pass or hand the ball off.
• Wide Receivers, Running/Full Backs & Tight Ends == Developers
  • These are the guys on the field that score the points. The developers write the code to get the project done [win the game]. Sure, the lead developer guides them [calling plays], but these guys have to write the code [move the ball] that results in a class, method, object or entity [score points].
• Offensive Line == Project Managers (PM)
  • Without an offensive line the quarterback, wide receivers and running backs aren't going to get anywhere as the defense will quickly run them over. The PMs are an essential filter [blocking] between the developers and everyone outside of the development group such as requestors, virtual teams, operations groups, etc. The PMs should be face-to-face [line of scrimmage] with all of these other groups making sure that the development team doesn't get randomized or thrown off track [tackled], but can focus on getting the software written [scoring].
• Defense == Testers
  • Just as I said in "the best offense is a good defense" a game can be decided by the defense instead of the offense. Your quality assurance (QA) team should be validating the developers' code throughout the project. This would be like how a football team practices against itself day-in and day-out, pitting their offense against their own defensive line. This is invaluable for the developers [behind the offensive line] as the testers [defense] are able to find bugs [tackles]. This allows the developers time to fix the bugs before delivering a product [game time].
• Coach == Architect
  • In The Mythical Man-Month, Frederick Brooks talks about how one person should own the vision of the project so that it has cohesion and unity throughout the complete development process. I see the architect filling this role since they are often involved with projects long before the developers. Think of off or pre-season while the players are doing their own thing the coaches are consumed by planning for the next season and the myriad of teams they will face. In software development, when the developers, testers and PMs have just finished a project and are going to training or getting miscellaneous stuff done they are not necessarily focused on the next project. Meanwhile the architects are involved in high-level discussions around infant projects [games next season] and how to approach them.
• Owners == Management
  • NFL team owners make the money decisions which involve business planning and hiring, but are pretty hands off in the day-to-day processes of running a football team. That's the role I see management filling. Management makes high level business decisions like staffing [player recruiting and trades], other resources and overall group direction. Management rarely gets involved in the low-level details of individual projects because they are focused on all of the projects as a collection [game records over multiple seasons].

Putting software development in this analogy helped me set some expectations of the people in my group. It seemed to simplify the equation for me. Instead of trying to figure out every little thing each person should be responsible for I was able to create a visual picture in my mind. It really clicked for me. What do I expect my PM to do? Well, they should be running interference for me [O-line] so I can get my job done [run the ball] and deliver the parts of the code I'm responsible for [score]. My lead? Should be guiding my priorities [calling plays & getting me the ball]. Our tester (SDET in MS lingo) should be poking all the holes [tackles] he/she can in the code I deliver [carrying the ball]. Our architect isn't actually writing code, testing or such [on the sideline], but they are extremely important in guiding the overall efforts of the project [coaching the game]. And management is not too involved in my day-to-day work, but they are looking at the high level stuff that's out of my scope.

I'm a simple man because, honestly, I felt a little better after thinking this through last night.

~tod

tags: software+development

When I first purchased dirtyDogStink.com and moved my blog over from Live Spaces, I knew that although the blog is the focal point of the site I didn't want it to be the landing page. I wanted a quick-loading, pleasant and simple design for the default page. My first attempt worked, but I wasn't too happy with it.

I wanted to create descriptions that would change in the main content area as you highlighted each menu option. Initially, I did this with images. I thought about doing it with JavaScript, but really wanted to try to do it without js while maintaining valid CSS. After several searches I found Eric Meyer's demonstration, pure css popups and it works! By using absolute positioning I was able to get all of my elements exactly where I wanted them with a changing description in the center of the page whenever a menu link is hovered over.

I like version 2 much better. Obviously I'm not a professional web UI designer, but I like this one's simplicity. My next to-do is to make some alternate CSS stylesheets that you can click on for different looks. That's for another day though...

~tod

You've heard of Jeff Foxworthy's "you might be a redneck..." catch phrase right? Well, Jeffrey Palermo has started his own: "you might have a legacy enterprise application...."

You can't figure out which copy of the source code is the one deployed to production.

The comments are worth reading too. Check 'em out. And yes, welcome to my world.

~tod

tags: software+development

A little over a year ago, I was making the transition from a systems engineer to a developer and posted that I was 'choosing C#' as my entry point language. Honestly, that was a bit naive of me. I didn't really 'pick' C# as much as I chose to learn the .NET languages which happened to include C# along with VB.NET and ASP.NET.

I'm bringing this up now because of Karl Sequin's post, titled Language Proficiency - C# or VB.NET? (found via JasonHaley.com). In a nutshell, his point is that a good .NET developer should be proficient enough to read and code in either language when the need arises. I couldn't agree with him more.

Over the past year I've primarily used C#, but the primary web application I work on is written in VB.NET. That means I've had to frequently flip back and forth between the two. Personally, I'm glad that I was forced to do that because it's made me a better developer. Although I feel more comfortable with C# I can read/write either language when necessary. And with the assistance of Carlos' CodeTranslator, I can very easily correct any syntax errors that inevitably popup when I switch between the two.

So the question really isn't whether you should be a C# or VB.NET developer, it's are you a .NET developer. I would expect any .NET developer worth their salt to be able to work in either language without losing too much brain power. So there you have it, the unadulterated opinion of an SE turned developer.

~tod

tags: dotnet