February 25, 2008

Playing

So I've reached Level 55 (Commander) in Call of Duty 4 and I'm not currently planning on going Prestige mode. Besides, it's not even available yet since I have to earn it as if it were Level 56. Prestige is a mode (or rather 10 modes) of reseting all that you've earned in the multi-player mode and starting over like new. The only thing you're left with to claim your badassness is a special medal next to your gamertag in-game. 10 prestige modes means 10 medals, but you have to go level 55 each time.... I don't think so.

The game is still fun. I haven't been let down since getting to take part in the Beta back last September (07). The single player is a solid play, action packed and a decent story and an ending that I thought was better than BioShock's (sorry Nathan). But really the most awe inspiring moment of the single player game was about half way through. If you played it you know what I'm talking about.

But the real crack addition that this game offers is the multi-player. It's fast paced and hardcore. There are 16 maps and enough game types to keep this casual gamer pleased for hours without pause. Sure I'm ready for the DLC coming next month, but that will also be competing with one of my FPS first loves:

Rainbow Six: Vegas 2. I've been a fan of Rainbow Six since I played the original on my PS1, although I didn't play any after that until Vegas on my 360. 2 comes out on the March 11th and I've decided to rid myself of Assassin's Creed for it. After all I did get all the gamer score out of that one and there really is no replay value in it for me. I thought there might be, but that would really just be a waste of time.

Until next time
Les

February 8, 2008

You're perfect! Don't change a thing

In our group's architecture meeting recently we (developers) were given a warning about code changes effecting (or is it affecting?) production. To sum it up we were told: "do not make changes unless they were absolutely necessary or be aware of consequences". And I'm wondering are there really any of us sitting at our workstations trying to think up changes to the system that aren't necssary? That aside though I'd like to examine the paradigm that this kind of warning is really introducing.

One thing to always remember as a software developer is that anytime you make a change to any system you are taking a chance of adversely effecting said system. Yes, there is a chance you could break something since no one and no system is infallible. So what do we do about this? Avoid doing our jobs? I guess before we can address that we have to define what it is we do as software developers.

Developers have a simple job. Write code to deliver software that performs requested functionality. No matter where you are or what you are developing this applies. It's simple I know. Too simple. But there are so many strings attached to that job description that you really can't sum them all up in a job posting of any sort. You have to consider that the code being written on day 5 is not going to 100% valid and in scope on day 35. Imagine the difference between requirements on day 5 and day 605. Software is a process. It has to grow which means it has to change. Scope changes. System requirements change. User requests change. The older a system gets the worse the code smells; no exceptions. So while a developer is in charge of delivering functionality they also have to consider these things: scope change; code maintainability; scalability; stress handling; and even the probability of the application surviving a complete system failure (or being usable after a zombie attack).

That being said, a developer knows that systems are going to require change. There are going to be changes that are directly related to user request and then there will be those changes required due to the need to *gasp* refactor (thank you Martin Fowler).

Sometimes its as simple as updating or migrating to a new tool in our application. A couple years ago we switched from using EJB2 to using a Spring container for our framework, it wasn't a user request, but we needed to change from using EJB2. That needed to be done for many reasons which I won't go into here. It required a lot of sweeping code changes. There were a lot of hiccups along the way some of which we're still running into. But it didn't end the world as our application knows it.

There are other changes though. Changes that aren't directly linked to upgrading or migrating tools. For instance, your application has been in development for 4+ years and is still growing. There are parts of the framework that are duplicated due to original configuration and short sighted development choices. Or even just the fact that code pool x is just to freaking big to manage and needs to be broken into smaller more manageable components. These changes won't offer any direct value to the end user (on the surface anyway), but they contribute to a cleaner more efficient code base. And a cleaner more efficient code base helps keep an application running smoothly, contributes to easier maintenance of the application, and also helps keep good developers sane (which is a good thing, insane developers do insane things like blame their tools for all their problems).

So, do we avoid these changes for the sake of what is stable now? If we do that it only helps those stable apps for now. What happens when that currently stable application in production needs a new feature or has a bug that needs fixed. Now you have to work in the mess that should have been cleaned up months or even years ago. Now making what should be a simple change is like trying to add a new floor to a four story building, but you have to add the floor in the middle of the building, not the top.That means that the chance of introducing more bugs into the system is multiplied (the risk is already there just because you're making changes in the first place). The change will probably take longer than it should. And on and on we could go with this.

Developers write code. Developers make changes to make the system better (for performance and maintenance). It is risky. That's a risk we're willing to take.

Until next time,
Les

February 6, 2008

Dev vs. Dev

Playing around with Google Presentation. Enjoy!