Month: February 2007

African Roses

I would like to write about the Hungarian notation, the good (not much) and the bad (quite a lot) of this source coding convention, but I really can’t. This matter sounds quite silly and irrelevant. My mind is still full of the images and the implications of the documentary I watched Saturday evening on La7. The title is “Rose d’Africa” (African Roses) and the author is Daniela Grandi. Unfortunately I cannot find the video on youtube nor google video, neither a summary on La7 website.
Well, what impressed me so much? The documentary brings hard evidence about the deep injustice affecting the African continent. An injustice that European and American corporations are feeding actively.
In Africa people actually die of starvation, sadly no news, but they are prevented from exploiting their fertile lands (such as near Tana River) because these lands are planted with roses (and other flowers) greenhouses. Flowers are grown and then sent to Netherlands for world distribution. Inhabitants, mostly women, are exploited in the greenhouses under terrible working conditions. The wages are incredibly low (basically we could pay for a pizza and a beer what they earn in a month), while they have basically no right. If they got pregnant, they work until the last day and then are fired. They are requested to enter the greenhouses just a while after the chemicals have been sprayed on the cultivations.
Moreover the remaining chemicals are dumped in the river, poisoning and polluting the environment.
Just outside of Nairobi (the Kenya capital) there is a huge slum where 2 millions of people live from what they can find in a nearby giant dump. That’s two millions! The slum has no sewers, no electricity and no water. The air is polluted by the dioxin coming from the dump.
All this is heartbreaking for me, deeply saddening, I can’t stand the idea of such suffering and waste. And I’m asking myself what can I do for helping…

The Good, the Bad and the Ugly

Engineers are supposed to deal with systems, usually large and complex devices that are expected to work. They are expected to work at least, but the common expectation is that they keep working reliably under a wide set of circumstances and mostly regardless of the environment. Consider any system that results from an engineering process (say a TV set or a car) from this point of view – it is not enough that the device works fine only at the seller’s location. This should put under the right light one of the most used programmer defenses: “It works on my PC”.

For us, as programmers and programming team leaders, the point of concern is how to deliver such robust products that could reliably work even in non-clean room conditions. A lot of entropy has been sacrificed to this goal and I don’t want to start anything new or propose any existing process methodology, I’d just like to recall what a friend of mine reported from one of his senior coworkers (thanks Xté).

This is a quick analysis that allows you to understand how much in good shape your project (or task) is.
Consider two nearly binary variables – working and understanding. You can get four combinations that identify four states of the system composed of the object the engineer is working on and the engineer itself. Here we go to analyze the four states (I swear, I’ll be brief).

It doesn’t work and you don’t know why. This is the typical state of the project start, you have this black box not working as expected and you are supposed to fix or implement it. This is not so bad if you have enough time to study, ask other people, analyze, and get your knowledge on what you need to do to fix it. Summing it up, this can be fair or bad according to the time you have.

It doesn’t work and you know why. This is quite good. After all, knowledge is power. With the knowledge you can both devise strategies and solutions and figure out the time or the means you need. Moreover, you have plenty of facts to explain the situation to the management and ask for the most suitable resources you need to accomplish the task.

It works and you know why. Perfect, you achieved your goal. You fully understand your system, and why is it working so that you can predict to a good extent when and how it is going to work.

It works, but you don’t know why. This is the worst case of all. Unfortunately, the rush and the wrong assumption that if it works then who cares, can lead to this terrible situation. The real problem here is that you cannot make any assumption for when the system will cease to work, you have no clue how to deal with it both to repair, move, or change. You have no warrant that the system will continue to work.
The fact that it works usually leads the project management to consider it complete and to make pressure to move on. A false sense of security may affect the team cleaning the way for greater disasters.

There are some quick corollaries to this analysis. First, always try to understand what are you doing even if it may seem like a waste of time. Second, always include a learning time in your estimations. Third, poking randomly around to fix things is a dangerous way to further damage a system while creating the illusion of work.

Programmers strongly rely on tools, basically, there is direct contact with the matter we design and develop, our tools are our manipulators and probes into the hidden work of electrons. We have to know our tools by heart. We cannot go away with a rough understanding of the language we use because we cannot afford our ignorance would let something in.

The natural question that could arise is: “What is the extent required for the knowledge?”. Does programming require me to understand OS internals? Digital electronics? Semiconductor physics?

Well, it depends. Gone are the times when a single man could brace the whole human knowledge and art in his lifespan. Nowadays we have to stop at a given interface, taking for granted that what is going on behind us is good enough. I think that you have at least a good knowledge of the first interface you are using, be it OS system calls, environment libraries, or hardware if you are working closer to the metal. Anyway, an average knowledge up to the next barrier could only be good when you are hunting for problems since it could help you to better exploit the environment and to get helpful hints to get you out of trouble… troubles where engineers spend most of their time.


I was on the train, fighting against that locust general, trying to reach the solar bomb to get rid of all his vicious breed…Well I did it… at least virtually. I completed Gears of War, game of the Year, winner of several prizes and mentions, and got the status of “Mercenary”. So long, so good. Having played the never-ending Serious Sam (I and II) I expected the game to be somewhat longer, but apparently gone are the times when a game lasted for tens of hours… or maybe I’m getting too good at playing. Unlikely, I would say.
In this game you play Marcus Phoenix that begins his quest in a prison (Unreal, anyone?), freed by an old friend, stating that the army needs his help. And in fact any help is desperately needed – the world has been taken over by the Locusts, a cruel race of creatures resembling of reptiles, they savaged the cities so that the government decided to bomb everything (smart move, isn’t it?). Roughly you have the task of mapping the caves of the Locusts and then activating a “solar bomb” to destroy them all.

The game is a 3rd person shooter and one of the best yet seen. The graphics is gorgeous, really delivering a full immersion to the player, is movie-like quality and the suspension of disbelief is very easy. Classic realtime graphics defects (such as polygons cut by the camera plane, textures revealing their pixel based nature, squared objects) are basically non-existent. For this reason and the abundance of gore, this title is really not suitable for kids.
The only dissatisfying aspect is that bulk objects (such as the choppers) are apparently without mass, their movements is not as smooth and … inertial as they should be. The best bulk “mass” simulation in videogame remains Halo 2.
The camera (aside from never ever letting you down), sports an involving war-footage style.
The game play is slightly innovative, and it is quite difficult given that the genre counts tons of titles. New is the need for the player to look for a cover in a firefight, you have to plan your moves quite accurately if you don’t want to be blown off.
You can carry two weapons. Aside from grenades, there is a basic set of weaponry – the standard machine gun (with a chainsaw), a sniper rifle, a bow with explosive darts, a rocket launcher and a shotgun. You have a non-standard “Hammer of Dawn” which is a targeting device for calling satellite beam attack on your enemies. The satellite attack takes quite a long time for aiming and works only outdoor with clear sky (and satellite coverage).
You have a team, usually just another guy the fight at your side. His AI is pretty brilliant – he usually don’t get into your line of fire and doesn’t stops you from moving around (or worst blocking while you are retreating, as it happened in HalfLife 2). In the beginning of the game he usually hints you for the direction where the game proceed. The game is never too difficult on the brain side, the most difficult puzzle you have to solve is find the switch aside of the door you want to open, nor you risk of getting lost – maps are pretty big, but the path is so marked you have no chance to get it wrong.
The only downside with the gameplay is that occasionally the “take cover action” interferes with the movement, or the crouched-run that you try to save your life. Just occasionally annoying. Also, if you are picky enough you could note some bugs here and there, such as enemy boss that slams into invisible barriers, or the multipurpose floating robot Jack that appears out of thin air. The worst bug I encountered was against a boss, I was expected to attract the boss on a carriage with a gasoline tank, then leaving the cart and throwing a grenade to let the carriage explode with its annoying passenger. Unfortunately the split second I throw the grenade the boss jumped on my wagon, causing the trap to explode and leaving me without any weapon to get him off.
But these are just minor quirks for a great game I really enjoyed.