Shortly after the Zune debuted, I purchased one. And I've been happy with it. It's done everything I expected out of a music/video player and it's gone with me nearly everywhere. So I was a bit saddened to pull it out this morning and see that the screen had been cracked. Not the external glass, but the internal LED screen. It's been a few days since I've used it. I believe the last time was right before SQL Saturday in Atlanta. It had gotten tossed in one of my laptop bags, one with plenty of padding, but it looks like a sharp impact to the screen still occured. I'm not sure if it occurred while it was in that bag or some other time. Though it still plays, I can't read a single thing on the screen, renduring the Zune unusable.

This morning I thought about what to replace it with and got a few bits of feedback from some folks on Twitter and on Facebook, but it'll be probably a month or so before I do replace it. There's a very good reason for the delay: it's not budgeted and I don't have money saved up for its purchase. The excess money we had saved up went towards a planned purchase of a MacBook about two weeks ago. In considering how I've used it over the last few months, I've realized that it's not essential for me to have a new Zune or iPod or other mp3 player. I have a PSP which mostly collects dust and for the purposes of carrying portable music and some podcasts, it'll do. I could go ahead and purchase a new player and throw it on a credit card, but like I say, it's not budgeted and the money hasn't been saved up and set aside for it. Purchasing on credit is not something I want to do for something that isn't absolutely essential.

This got me to thinking about projects and resources and how they get allocated. We all what resources and focus on the things we care about the most. For me, that has usually been the security side of things and now it's ensuring that we get good code that performs well against the databases I support. But there are a lot of things that need to be done to bring a project to completion and sometimes you have to compromise in certain areas to get to the finish line. This means sometimes not having the resources to crank every bit of performance out of each and every stored procedure and data access code. Often the resources that would do that are busy working on bugfixes or supporting the implementation of those bugfixes. And that means that stored procedure code base which is performing okay is left at performing just okay.

When I have served as a project manager, I have understood this dynamic and accepted it. It's part of the trade-offs you have to make to ensure resources are assigned to the proper areas to complete the project. But as a technician I've realized sometimes that I have a very myopic view of an application or project. Of course I want the stuff that's important to me fixed first. However, in the grand scheme of things those things may not be of the highest priority. But I'm only seeing the things that impact me. I'm not taking a step back and getting the bigger picture. And sometimes I've made a big deal out of it. And some of those times the PM doesn't take the step back either and assigns the resources to my priorities when he or she shouldn't. It's the same as buying a new mp3 player on credit.

As technicians, when there isn't enough resources available to complete all the wants for a project, it's time for us to take a step back. We need to try and understand where our needs fall within the other needs of the project. Does our needs truly deserve priority? If they do, then we should detail why in very clear language that explains the impact of not getting to what we want to see accomplished. There is a great temptation to exaggerate a bit, but that doesn't serve us well. We may get priority on this project, but what about the next one? If we've exaggerated the impact and that is seen, then the assumption is going to be that we always exaggerate our issues. We'll become like The Boy Who Cried Wolf. And that story didn't end well.

Maybe our issues don't get resolved by the end of the project. But if they are legitimate and we've documented them well, then our organization knows about them. Hopefully they don't get forgotten about. If our write-ups were well done and the project had the right visibility, they won't be forgotten. And they'll eventually get the resources needed to solve the issues, if those issues show themselves to be painful enough. That's like saving up and buying the mp3 player when the resources are available. We don't overextend the organization or burn credit we shouldn't for something that isn't absolutely critical. All around, it's the smarter choice.