Once again, and customarily around November, we settle down to the slow, tragic crawl of our favorite NFL football team and the realization that the Minnesota Vikings will probably not qualify for the playoffs this year either. And so, traditionally about the time when grinning pumpkins pop into the windows and kiddies run around yelling “trick or treat”, our focus shift to beating Green Bay Packers instead.

The Vikes went up against the New England Patriots last Monday night. The result was that the Patriots outperformed them – on the Vikings home field – with a humiliating score of 31-7. Which means that we (the Vikings) are now 4-3, just one win ahead of the Packers 3-4.

We saw a funny T-shirt when I was in Minnesota this year: “I root for the Vikings and whoever is playing the Packers.” The friendly animosity between Minnesota and Green Bay is well-known. And somehow, every year, it all comes down to whichever team is going to crawl across the finish line between the two. With the Chicago Bears running a 7-0 record this year, even crawling across the finish line seems out of reach.

But at least, at least let’s beat the Packers. After all, this is the ultimate defeat: Losing against a bunch of cheeseheads.

This has been my nemesis of lately.

Error 0xc0000005 means that there’s an Access Violation in the code; namely, some part of the program tried to access a memory location that was invalid. It means, usually, a construction fault within the program.

Except, in this case, when the environment you’re working with is so faulty that the script you’ve written causes the program to crash. You’re not doing anything wrong, but the program fails to handle the situation because it’s incredibly inept, makes an error somewhere with its pointers, and then BOOM! an exception occurs.

It goes downhill from there.

Trying to write this script, which I presently have been assigned, is rather much like trying to move a dunghill from point A to point B, using a pitchfork that keeps breaking every time you try to shovel.

Free soda. :)

I’ll be going for the Coke and Fanta. I hope my dentist doesn’t see this.

Maybe everything happens in waves?

Waves are central to the foundation of the universe. The quantum wave-particle dualism means that all matter, every single atomic particle, behaves like a wave.

I was out walking one day about a year ago when I looked at the ground and saw – it had just been raining – that the water on the ground didn’t stream like a continous flow, but as a number of small, tiny waves. I realized that, probably, it was a more efficient energy configuration for the water stream.

And that got me thinking. The most efficient military concept is to attack in a wave, pouring soldiers out in a mass concentration of strength. And we develop software in a similar way: we become more efficient if we concentrate during a limited time on a subject, finish it, and then switch our attention somewhere else. The focus becomes clearer, and we become more efficient.

So instead of working in a slow, steady pace – maybe it’s more efficient to behave like a wave. Concentrated focus, slack off, concentrated focus, slack off… for a multitude of projects. For business it might be best to focus on one thing to 100% during a limited time, and then switch focus (the switching itself being a time of preparation, rest, and catching breath), and then focusing on something else to 100%.

Incidentally, that’s kind of how the SCRUM process works.

Along with my recent interest in Irish folk music, which I’m sure has nothing to do with Miss Northern Ireland, I’ve found a song called Willie McBride.

Ah the sun now it shines on these green fields of France,
The warm summer breeze makes the red poppies dance,
And look how the sun shines from under the clouds;
There’s no gas, no barbed wire, there’re no guns firing now.
But here in this graveyard is still No Man’s Land,
The countless white crosses in mute witness stand…

The song moves me very deeply. World War I was madness… just madness. One million guys in trenches firing with everything they had – machine guns, gas weapons, artillery, bombs – at the other million guys entrenched a hundred yards away. And neither making headway. Mobility was achieved merely a few times during the war, on the western front.

“Did you really believe that this war would end wars?” they sing. The war to end all wars, indeed. Colonel Potter in M*A*S*H ironizes over it, remembering his fallen friends: The one who died in the “war to end all wars”, and the one who died “in the war after that”.

When Napoleon I set out to invade Russia in 1812, he began with an enormous army of 422.000 soldiers from all over Europe. They fought all the way to Moscow. Much like the German armies of World War II, they got caught in mud, bad weather, and when they entered the burned capital, the winter came. The retreat was an endless agony… men freezing, starving, dying in heaps along the way. The slow, agonizing retreat through the snow… and then the Russians move in with their cannons. In the end, less than 10.000 survived.

And Guy Sajer, the french man fighting for the Germans in World War II, tells his story in his book “The forgotten soldier”. Driving trucks endless miles through Russian winter and temperatures of -20 F to supply the enclosed sixth army in Stalingrad, hands, feet and faces burn from frostbite and people die from freezing. (Of the hundreds of thousands of soldiers in the sixth army, only 6.000 returned home to Germany.)

Is there then no end to war? With every book I read, war becomes even more terrible. What happens to the collective soul and spirit of a nation that sees four hundred thousand of its young men lie dead like heaps of rubble, leaving fathers, mothers, wives, girlfriends, children behind?

And how enormously and terribly deformed will the heart of the nation be that sets out on a lunacy like this? What drives a nation to invade another without sane reason or purpose?

Did you leave ‘ere a wife or a sweetheart behind?
In some faithful heart is your memory enshrined? …
…or are you a stranger without even a name,
Enclosed forever behind a glass pane,
In an old photograph, torn, and battered and stained,
And faded to yellow in a brown leather frame?

I stumbled across this little gem today. If from a page of how to shoot yourself in the foot in any programming language. It was full of how to shoot yourself in the foot in Visual Basic, Prolog, C++, and many others. But this one was the best.

UNIX:

% ls
foot.c foot.h foot.o toe.c toe.o
% rm * .o
rm: .o: No such file or directory
% ls
%

Once upon a time, a Task was given to a young engineer. The engineer was delighted to start working upon it, since this was his first big task to do within the big system he was working with. “It’s not a funny task”, cautioned the Master Programmer to the young engineer. Nevertheless, the engineer sat down to examine it, for he was very interested in building this great Task with which he was entrusted.

He went to his room, and examined the Task in detail. It was small, and round; and when he held it in his hand, it seemed to be strangely heavy. He placed it carefully on top of his desk, where it rested gently. He turned his attention to the system infrastructure into which this great Task would be incorporated. Many hours passed, indeed, days passed without the young engineer rarely lifting his eyes from the specifications. He went home to sleep, and came back early in the morning and continued where he had broken off.

When he finally lifted his eyes from the papers, he happened to look at the Task. To his surprise, it was no longer a small object, it had grown in size and was now about a foot in diameter; and it seemed much heavier than before. He looked at it in amazement, and wondered how it could grow like this. And he realized with a sigh that it would be more difficult to incorporate it now. The Task would require further study, and further experimentation, to fit into the system.

So he went back to his papers, specifications, and documentation. He pondered and he read, he studied until his eyes were red from tiredness. And at long last, he sat up again, and thought to himself “Now I have the answer! Now I know what to do!”

It was then that he saw that the Task had grown even more! It was no more a foot in diameter, it was now a huge, black sphere, over a yard across! The engineer didn’t know what to do. He said to himself: “My initial estimates must have been grossly wrong! I must study much, much harder”, for he was still determined to solve the problem and incorporate this great Task into the system.

So he went back to his papers, specifications, and documentation. He studied so hard, he worked so much, he tested and implemented and debugged so brilliantly, that after weeks and, indeed, months of hard work he had produced a solution, a great environment, into which the Task could be fit. And then, as he went to fetch the Task, he had the shock of his life! The Task had now grown even more, and was not only a yard across, but it occupied the entire room in which he sat!

Discouraged, and at a loss for any explanation, he went back to the Master Programmer to ask him why the Task kept outgrowing his solution. The Master Programmer looked at him and said:

“The Task grows because it has not yet been fully defined. Every task is first incubated, and then hatched. When it is first hatched, it is very small, and it was in this shape that you received it. As you kept studying and researching, you added definition upon definition to the task, and this caused it to grow bigger. It continues to grow until it has been fully researched. No one knows how big it will be by then; not the engineer, not the architect, and not the project manager. This is a great mystery.”

The young engineer then asked “so what will I do with this Task I have been given?” The Master Programmer replied, “You cannot limit the size of the Task. But if you choose your environment carefully, you can have more fun while researching. This is why you should always code in Delphi.”

And thus the young engineer was enlightened, and walked away.

I don’t know if there is a good way and a bad way of using Stored Procedures. My experience with them so far has been pretty limited. I’m sure that there are wonders that can be achieved with them. At least they should be pretty efficient at cutting down data transfers between server and client, in some scenarios.

But the way they are used sometimes makes me wonder. Does every single SQL query have to be a stored procedure?

The web application I’m working on right now uses stored procedures for all CRUD database accesses; every single select, insert, update and delete is a stored procedure. And moreover, all stored procedures check session data, verify data, update tables and perform random application magic.

So, uhmm, yeah… things might go a little bit faster. Not noticably, I’m sure. But the dramatic downside of it is that it is impossible to change any data format, any table, any database access code without also having to change the stored procedures. The logic becomes stored both in the ASP code, and in the database itself; they are invariably and inseparaby tied together. The web application can not function without the code in the database.

This means a few things:

• You need to maintain an increasing number of items.
• You can’t switch the backend easily since the backend is part of the code.
• You become tied to one single database vendor.

For developers, we typically achieve the highest development speed when all the code needed to be changed is conveniently located in one, single place. If every little change requires changing code in a number of different locations, a very tangible inertia sets in. And with every additional location, the inertia grows exponentially.

The number of editing locations can be many. Front and middle-tier COM objects, stored procedures, XML files for language definitions, other definitions, configuration, several ASP files all depending on each other…

I feel that I am ready to formulate the First Law in an upcoming High Mobility Development methodology:

The time and effort required to implement a feature is exponentially proportional to the number of disparate items (files, data stores, deployment locations, databases) that need to be changed.

The inverse is of course also true: By keeping the number of items low, it is easy to achieve a rapid implementation of new features. And that is the essence of High Mobility Development.

There’s a site I love which is called www.thedailywtf.com [UPDATED]. It is full of real-world examples of code, which at some point or other has caused programmers maintaining that code to exclaim various colorful phrases forbidden to younger ears; code written so poorly that jaws are dropped, coffee mugs crash on the floor, little children start crying. Code that innocent people should never be allowed to see. Code that controls heavy machines at the building site down the street.

From time to time, I think it’s amusing to go there and see what “interesting” code is out there. And you moan and writhe in agony at the poor programmers who have to maintain it, or clean it up.

And then it hits You.

Like in that sudden moment when a moose suddenly walks out in front of your car on the highway; like the engine outside the airplane window that suddenly catches fire – this is not supposed to happen to You. It happens to other people, but not You. You… are safe.

As the letters and paragraphs of code slowly scrolls over the screen, a feeling starts rising from your gut, grabs your heart, moves its way up the throat and then slowly, deftly immerses your brain in a tightening, choking grip.

Panic.

This is it. Welcome, my friend, to Gulag. This is your job; the one you chose. And which you are going to maintain for the foreseeable future. You have inherited the code written by a long series of predecessors, and which has been poorly constructed, poked around in, debugged, patched, and beaten beyond recognition, for years and years.

The panic keeps rising. In your mind you’re pounding the walls, slamming the doors, breaking windows. You imagine storming out of the office, quitting, letting go forever, start driving taxicabs or plant flowers for a living instead. But you don’t do it, because you’re the new guy, and you chose this job, and you’re getting paid nicely for it; and moreover you’re a calm, sensitive person, not prone to emotional outbreaks or fits of rage. So you sit there, nicely and quietly, and stare at the paragraphs slowly scrolling across the screen.

But inside, you’re screaming in panic. And no one can hear you.

Our fish tank has already shed its first victim.

Who knew that the peaceful, tranquil aquarium that glimmers so beautifully in our hallway, actually is a wild, bizarre deathtrap where those fish who aren’t fast and furious become lunch for those who are?

It is a relentless hierarchy of fish. Between those who eat, and those who are eaten.

The evidence we saw yesterday was a fish spine that was left on one of the rocks on the bottom. The gruesome picture posted tells its own story.