Bring It On

Just in case you're not aware of it, there's a great TV show called Battlestar Galactica. It's a remake recreation of the original show from the seventies, but much darker and more realistic. Despite the sci-fi setting, don't let that fool you - the show treats many timeless human issues like meaning of life, love, religion, betrayal...

I won't go into detailed analysis of why this show is so good but one thing is obvious: without the most excellent soundtrack that keeps getting better season after season the show wouldn't be half as good. The music is original with lots of unusual instruments and expresses emotion in a way previously unheard of for a TV series.

The last season's final episode was a shiny example of that: perfect synergy of picture and sound, great timing and excellent execution.

Now, just a couple of episodes later there's another genius example of the use of music and lyrics to enhance the viewing pleasure. In the episode 7 of the season 4 (warning: spoilers ahead! If you haven't watched the episode, don't read further) called Guess What's Coming to Dinner we all witness great vocal capabilities of the actor Alessandro Juliani (aka Felix Gaeta).

While recovering from the leg amputation Gaeta sings to reduce stress and cope with pain. The lyrics are original and so is the music, but the way the song is delivered will send chills down your spine. The song is appropriately named Gaeta's Lament and both the lyrics and music sheet are available.

Even better, a thorough analysis of how the song came to be and how it improves the narrative, especially at the end when the hybrid is awaken (awesome scene!) can be found at the Bear McCreary's blog. I highly recommend you to go through it. Considering how much thought and love when into making an episode like this no wonder it turned out as good as it did.

Relation between developer's quality and compensation is a hot topic. Lots of e-ink has been spilled over this issue but not much crystallized in the end. Unlike lawyers who have established a baseline price of their work, developer's pay fluctuates wildly and is not necessarily related to the quality of their work (in fact, more often it boils down to how good negotiator you are). Quite often you'll see developers (who recently started contracting) asking for help on how to price their work on a public forum. Clearly we need some kind metric to measure developer's productivity, but even more we need to understand the quality of the work, more than the quantity.

Martin Fowler's Cheaper Talent Hypothesis is a great read that covers many important points. The relevant piece that talks about quality says:

Faster cycle time leads to a better external product, but perhaps the greatest contribution a talented team can make is to produce software with greater internal quality. It strikes to me that the productivity difference between a talented programmer and an average programmer is probably less than the productivity difference between a good code-base and an average code-base. Since talented programmer tend to produce good code-bases, this implies that the productivity advantages compound over time due to internal quality too.

I'd say this is actually the most important aspect. Of what use is the ton of code if it doesn't work? In one of the previous companies I worked for, an informal study showed that every bug that ends up in developer's lap (confirmed bug that needs fixing) costs the company, on average, one thousand euros. The reason is not that developers' time is expensive, but that the problem needs to be processed by support personnel, repeated, described/documented and after the developer is done fixing, the issue needs to be confirmed as fixed.

Think about this. With a couple of bugs "generated" a cheaper but lower quality developers will nullify the salary difference. Or vice-versa: with each bug not created a more expensive but higher quality developer will cost you less.

Unfortunately not many (if any) companies look at the problem this way. Usually the only metric is how fast one can reach the "finished" product state. The time spent in fixing all the issues introduced by rushing the product out of the door never "counts". It's a shame.

Even though we've been in the era of many-core processors for quite some time, not many developers bother to change their habits and try to use all that power. In fact many work for years without a single multi-threaded/asynchronous line of code written. A colleague of my wife was startled recently when she realized that she was supposed to write some asynchronous code yet she's been a developer for 3+ years now.

Fortunately Silverlight 2 is going to change all that. Due to the fact that Silverlight's UI runs on a single thread (just like all of the UI code on Microsoft platforms) and that most if not all network code does take time it would be unacceptable if the Silverlight plug-in would just block thus blocking the UI of the host (Web browser like Firefox, IE or Safari). Therefore the API designers decided to only use asynchronous model for each and every network related call.

Have a look at the WebClient or WebHttpRequest class and note there is no way to synchronously download a web page or any other content. While this is for sure going to confuse all those who ignored the asynchronous pattern in the .NET it is also going to force them to finally face it and use it.

I think this is a good thing. The asynchronous pattern in the .NET is very well done and deserves to be used more not just in Silverlight but with desktop applications too. There's no excuse today for a developer to create any application with a periodically unresponsive UI.

IL code is platform agnostic. So as long as there’s a JIT compiler for your processor everything should work just fine. That’s why by default the compilation mode for a regular .NET project states “Any CPU”.

The image you get when compiling the application or a class library will always contain IL*, but you can force the platform compatibility with a special flag (that can even be turned on and off post-compile). Why would you ever do this?

Because if you’re using a mixed assembly which is partly IL and partly unmanaged native code (usually C++) then you are already tied to a platform.

This problem shows up mostly when you try to use native (or mixed) 32–bit class library from a pure .NET application.

Fortunately, the solution is easy – you don’t need to mark all of your assemblies as 32–bit (x86), just the main executable. Once that starts in x86 mode, all the other DLLs will load as x86 too.

Why worry about this? Because more and more people will be using 64–bit OS-es now that memory is dirt cheap (you can never have too much memory). Out of three computers I use on a daily basis, two are 64–bit (XP and Vista) and only one is 32–bit (XP). There is a good chance I’ll soon be replacing the remaining 32–bit laptop with a new one with a 64–bit Vista.

*Unless you ngen the image, that is.