Tuesday, June 24, 2008

Working with others = my glass ceiling

I've never really worked on projects that involved more then 3 people on the development side of things. That is, until January this year. At the start of this year my department started working on the biggest, most important piece of software we have ever build. And almost everyone from my team is involved. It's currently a 10-man project. 6 of which are developers.

So now we're 6 months in and we in the phase where I get to dig around in other peoples code. Be it for fixing bugs, or just plain and simple code reviews. And now I've started to notice something negative about me. I've noticed that I regard code that has not been written by me as bad code, even before I've take the time to examine it. I didn't notice it immediately , but I've started noticing it this week and thinking about it it explains some of my feelings towards certain modules.

Since I think the code is bad, even if it is better then what I would have written, I always want to refactor it, change it. And that's not good. Well sometimes it is, but not always. And when I do a code review I should pay particular attention that I judge code on how it works and not how I feel about it.

As a programmer you can get only so far flying solo. To progress as an effective programmer you must also learn to work well with others and be part of a team. This is something I know, but my unconscious doesn't appear to want it. Now I know I can start working on it. And in the end it will make me a better programmer.

Wednesday, June 18, 2008

I've never liked DRM

This time nothing about programming, but about my other great hobby: video games.

I recently bought Mass Effect for the PC. And it truly is an awesome game, but even though I bought it and I have the 2 DVDs lying right here on my desk, I never installed it. Instead, I downloaded the illegal, cracked, version and installed that. I figured it's not illegal since I did in fact buy the game. I also registered the CD key on the Mass Effect web site, so they know the game I bought was bought by me.

Why did I install the cracked version and not retail version? DRM.

The retail version comes with the SecuROM copy protection. But I don't consider it protection of any kind. It's system crippling software, that creates security problems on your system, makes it slow and unstable and only because the big video game publishers consider you a pirate no matter what. Mass Effect takes it even further. It requires you to activate the game and you can activate it only 3 times. After that you must purchase (yes, you must buy a new copy of the software) a new CD key. They planned it even worse. They wanted the game to require re-activation every 10 days. But after public outcry they changed that to unlimited time, but only 3 activations.

So when do you need to reactivate? When you get a new system. And a new system in this case is when you reinstall Windows, or replace some hardware. From an article linked above it seems to consider a new video card to be equivalent to a new system. That's as brain dead as Windows Vista needing reactivation because replacing my WiFi card must mean I have a new system.

Normally people would "vote with their money". Not buying the game would send a clear signal, but I think that in this case it would only play on the paranoid minds of the publishers. If people didn't buy the game because of the DRM, they'd just figure people where pirating it and they'd need more DRM the next time around. Never even considering that the DRM is what made people not want to buy it in the first place!

When will these people get it into their fracking heads that DRM is a big burden for honest consumers who bought the product, while it's no problem at all for the pirates. The game is cracked, the DRM removed, as soon as the game is available. It's just pestering the people who pay your salary. And it should stop!

Sunday, June 8, 2008

Counter-intuitive optimisation

I've always been interested in game programming. I never actually managed to create a full, completed game, but from time to time I do start another project. Currently I'm messing around with the XNA Game Studio 3.0 CTP. When Googling for some answers on some game-programming-related problem, I ran into a developers journal on GameDev.net. The journal was pretty interesting and I started reading all the entries. It's about a developer who's creating a space MMO. This particular developer mainly focuses on the graphics engine, so while all the specific graphics lingo and math is lost to me, I do understand the more general programming bits and one bit really surprised me.

On November 7, 2007 he wrote a piece about optimising a noise function. His project uses a noise function coded in a high level programming language and it appeared too slow. So this developer decided, like many other developers would, to rewrite the function in low-level assembly to gain performance. This kind of manual optimisation is very hard, but generally yields pretty good results. But when he hand-optimised the function it wasn't faster. In fact it was 2 times slower then the implementation written in the high-level programming language. Programming in assembly language is hard. It's very low-level and you need a really good understanding of how the CPU architecture works to get the best out of it. So it's not surprising that a compiler written by a lot of very smart people will produce faster code then a single, simple developer can product on his own. But this didn't appear to be the problem. No, the problem was using a lookup table.

A lookup-table is a very simple (and usually very effective) optimisation technique. If the calculations are slow, but limited in volume, it's easy to just calculate all the possible values one time and store it so that later calculations don't need to be calculated, but can just be looked up. In a lot of game-programming books I read this was usually the first optimisation authors would recommend. It's easy and it just works. Not anymore it seems. After the developer had reprogrammed the noise function in assembly language the bottleneck didn't appear to be the calculations, but the memory accessing in the lookup-table. So by eliminating the lookup-table and just calculating each thing every time, he made the function faster. And that is not something I would have though of.

The funny thing is, this is actually something Steve McConnell warns about in Code Complete. In this excellent book he warns about optimising performance by 'guessing' what's faster. Things that 'feel' like they would be faster aren't necessarily faster. And things that where faster last year, won't necessarily be faster on this year's CPUs, compilers and operating systems. The only one true way to determine what is faster and what is not, is by measuring.