The Blind Fireman

There’s more than one way to skin a cat, or so they say. Similarly, perhaps, there are many ways to successfully lead a development team, small or large. Having done the former in various capacities I’ve learnt a lot about people, myself included, and there’s one conclusion I can’t ignore: it’s a fickle business. Books like the oft-praised The Pragmatic Programmer
lend the wisdom of elder programmers and analysts (which reads somewhat like a Carnegie self-help book, but I’m only a third of the way through) who’ve done and seen it all. Nothing keeps you learning like the real thing though…I’m still inexperienced; I can still learn more; I can always do better.

If I were to share one lesson, it would be what I coin “The Blind Fireman“.

The comparison

Programming solo or in a team is complex. It requires concentration, analysis, open communication, rubber ducks, knowledge of the language you’re using (or not), knowledge of what you’re producing, knowledge of your users, knowledge of your tools and so on; it favours the experienced, those who’ve done it wrong in the past and learnt the hard way. Little wonder, then, that it’s difficult to get it right first time, if at all. Taking all of this into account should affirm how complex the situation is. How much effort and understanding it takes to succeed in getting a product out the door. I think in some ways this is why what someone once said “complexity has nothing to do with intelligence, simplicity does” is so relevant.

Now fire-fighting is surely more complex. It’s certainly far more dangerous than sitting at a desk 8 hours a day pondering APIs, inheritance and polymorphism. I imagine it takes bravery, concentration, analysis, teamwork, tools, knowledge, risks; use certain tactics and equipment for various different types of fires, temperatures, environments.It sounds far-fetched, therefore to even mention a programmer and a fireman/woman in the same arena professionally, but consider the following if you will…

The story

You’re a fire-fighter (woo hoo!). You’re sitting down and sipping a cup of tea at the Fire Station, reading the local paper when suddenly the alarm goes off: there’s a massive fire at the local furniture factory. Parts of a three story building are ablaze and people are trapped inside. You gear up, jump in the fire engine and head to the scene.

Fast forward a bit and you’ve taken the briefing from the chief fire-fighter. The fire’s on the second floor. You’re climbing the stairs in your equipment; mask, tank and the like. Looking upwards you can see there’s a lot of smoke. It’s crawling along the ceiling slowly. Swirling and swishing its way around. You reach the top of the stairs and you realise you can’t see much, if at all. Where’s the fire? How would you know? You feel your way along the corridors; your only indicators are the heat emanating from the room ahead and the roaring sound of sofas and chairs being devoured. One of your main sensors – sight – is out of action, how do you stop the fire? Do you keep going? Do you communicate with your team? Both? Would being able to see just make the challenge a whole lot easier? How about a nice, cheap but reliable pair of thermal imaging goggles, complete with HUD and video cam for relaying what you’re seeing to the team outside? [Granted that's all easier said than done]

The explanation

Though extreme, I see this analogy as a warning for lead developers on the importance of “getting their hands dirty” when heading up development efforts on a new or existing code base; for the managers of such people on recommendations to their senior programmers and a suggestion to be made by those under either of the two. Don’t design blind!

The fireman/woman lost one of their main senses, and this adds to the complexity and difficulty of the situation or task at hand.

How can you decide what code needs changing – where, how much and why – if you’re not writing code in the first place? How can you steer your co-developers in the right direction programmatically/design-wise/tool-wise if you’re not using what they’re talking about?

To put it another way: can you really trust your design decisions if you don’t use what you create? How will you know it works in reality? When it’s too late?

The conclusion

It’s easy to get get bogged down in the politics, analysis and organisation of programmer leadership; perplexed, pressured and warped by the needs, wants, desires and craziness of “the business” (your users!). Resist it all and set yourself programming tasks at every stage of the project, because seeing the fire is half the struggle to putting it out in the first place.

Battlefield Bad Company 2 (Xbox 360) first impressions

Some initial thoughts halfway through my most anticipated sequel this year…

The story’s poor. What am I doing really? You find this guy, now this guy, oh here’s something different: find this place! Whilst you’re doing that random people will pop up like something out of Time Crisis 2 and try and kill you. Oh and to do all that you go through a million different checkpoints. That’s what MW2 did and it f-cking sucks. It feels really scripted to me and I hate it for that. The ‘level’ interaction seems unfinished. For instance when you run into the castle-esque areas on the desert map (de targo or something?) you affectively initiate a mission or new sub-story sequence that ends in a boss (i.e. a f-cking great big Apache helicopter). Once you’re done, the screen fades to black, you see a random cinematic sequence where Haggard says something odd or funny, and suddenly you’re outside with your vehicle and squad (which, by the way, are popping into view from top to bottom like something out of a tech demo). Christ.

Oh, and that annoying bug with the loading screen: you’re reading the tip text then it fades to black. You think “great, the level’s starting” and suddenly the text’s back and you’re loading again. Huh?

The action is outstanding, second to none. The gadgets, guns and vehicles are much better than before; they feel more realistic and reactive. The destructive environment is also an improvement on the first (which wasn’t bad in the first place!). The textures look amazing and the game looks ever-so realistic. The Brazilian jungle was actually beautiful.

It’s a good, fun game, but the thing that made the first Bad Company instalment so good was its open-ended gameplay and well-polished storytelling, both of which have taken a back seat in #2 to do what seems like its competitor does: all looks and no substance. Grr!

That said, I’ve yet to play multiplayer which is where Bad Company 1 really got going.

Ant TODO Update

Quick update regarding Ant TODO: there’s now a JAR available for download, so you can get it running even quicker!

Ant Task for TODOs

I often felt the need to scratch an itch when it comes to source code and a little fragment called //TODO. It’s scattered everywhere; I’m sure you’ve seen it. Yet no matter what codebase you’re looking at, there’s never any real exposure to them.

I therefore decided to implement an Ant Task for parsing TODOs in source code. You can read more about it over on the Google Code project. Please feel free to review code, suggest features or try it out and report a bug.

Happy new year to all; many happy returns.

See you in 2010!

Sky Songs and Linux

If you want to use the Sky Songs download client in Linux (say Ubuntu or Debian), just paste the following into a file called skysongs in $HOME/bin and then chmod a+x it:
cd $SKY_SONGS_DIR; /usr/bin/java -cp . -jar downloader.jar $*

Note, $SKY_SONGS_DIR should be changed to your installation directory. If you used wine to install Sky Songs, have a look under /home/YOURUSERNAME/.wine/drive_c/windows/profiles/YOURUSERNAME/Local Settings/Application Data/Sky  Songs/.

Sky Songs works by giving you “SKS” files that describe to its client (“Sky Songs MP3 Downloader“) what and how to download; i.e. your songs. Once you’ve downloaded one (say Renegades.sks; the “Renegades” album by Rage Against the Machine), just execute the skysongs script as follows:
alex@prometheus:~/Music$ skysongs Renegades.sks

Thankfully the Sky Songs download client is written in Java so it’s not only cross-platform but its structure is obvious.

Please note that these instructions are absolutely not intended for circumventing Sky’s download procedure, nor are they to be used to break the Terms of Service you’re most likely bound to by law. This information is purely for educational purposes and to assist those who are new to Linux get to grips with their everyday software in a new environment.

Ignorance

The problem with ignorance is not only the laziness of the culprits, but the hatred expressed by those who are better informed.

Google Wave Extensions Python API – Annotation Documentation

Quick post documenting the much-sought-after structure of the Python API’s Annotation name/value pairing. If you want to annotate a blip’s content, you’ll need to utilise the values below:

  • conv/title
  • lang = en
  • style/fontWeight = bold
  • style/fontStyle = italic
  • style/textDecoration = underline
  • style/textDecoration = line-through
  • style/fontSize = 2em
  • style/color =r gb(229, 51, 51)
  • style/backgroundColor = rgb(51, 127, 229)
  • link/manual = http://example.com/

A Python example of using the above:


msg = "This is a message for you"
doc = wavelet.GetDocument()
doc.SetText(msg)
doc.SetAnnotation(Range(msg[-4:], len(msg) - 1), "style/fontStyle", "italic")

The above should italicise the word “you” in the variable “msg”.

According to Google employee ‘Pamela’, this isn’t set in stone “as we aren’t confident in their stability”. Thanks to Dave of the same Google Group thread for documenting and posting the styling annotation name and value pairs.

Hope that helps someone ;)