Thursday, May 28, 2009

Using SVN to find diffs on repositories

Try something like the following :

svn diff -r779768:779000

which will produce file names and diffs between those two revision numbers of a code repository under svn control.

Saturday, May 16, 2009

SOA . . . Is that All ?

I originally wrote this entry on October 5, 2004, and published it on

So, do I really get to cook SOA with these 10 ingredients? On ingredient number 6 (Governance), at least, I'd recommend another look.

Monday, May 11, 2009

Production or Maintenance & Support

In The Cathedral & The Bazaar, Eric S. Raymond estimates that 75% to 90% of software business *effort* is not spent on the production of "products" but on support and maintenance of software products and systems. The sources of Raymond's claim are interesting in themselves ...

Sunday, May 10, 2009

Bugs Lead to Existential Questions

I originally wrote this entry on September 30, 2004, and published it on

There are some who believe that we only switch from our "being" mode to our "thinking" mode of existence when something breaks down.

Let me give an example to make things clear.

Say, you're walking in Central Park in New York City towards a bench to sit for a moment.

As you do this, you're not constantly thinking: "Oh, this is a bench; now I'm 10 yards from it; it has 4 legs; it is painted green ; now I'm 4 hards from it; it is made of wooden planks and the legs are steel, etc. . . ." (Are Central Park benches green and made of wooden planks and steel? Or are they coming in concrete these days?)

If we thought in this fashion and of all these details, we'll go mad very quickly. Instead, we simply go and sit on the bench and enjoy the fresh air. That's what I like to call the "being" mode of existence.

Now, if the bench breaks beneath you as you sit, it will probably lead you to fall.

At that point, you will start going over everything that is supposed to make it a bench and wonder what went wrong, what "broke," what was not as it was to be. That's what I like to call the "thinking" mode of existence. A mode that deals with bugs in the existential environment.

So, it should be no wonder that the best way to start learning and thinking about existing, complex code and the process around its production, is to start by debugging it. Once the code is known and navigable, we become comfortable and at home, returning to the "being" mode. We become the code and know it as us.

Which mode is prior to the other? For which mode are we best tuned? Which is a "better" mode? Is code a place to be or a place to think? Is code even a place?

I don't know the answers to these questions.

What I do know is that every software engineer (or urban professional for that matter) needs to get out some times to see the world, take a bicycle ride (1, 2) or go on a simple stroll in the park, to sit on a bench, preferably made of wooden planks that won't break.

Friday, May 08, 2009

Open Source Society

I originally wrote this entry on September 19, 2004 and published it on

We (and this does not include just the U.S.) are already an open-source society to a very large extent. Information is widely available for those who care to find out and some have proven it possible to do so by their own example.

However, open dialogue matters well above and beyond open source.

Mixing, on the importance of which to innovation Lawerence Lessig has built a whole case, is simply an instance of open dialogue.

Open-source (widely available) information might be a pre-requisite for substantive dialogue but it neither replaces or guarantees it nor leads to it.

Finally, there're those who believe that what matters most is not cyber-dialogue but committed, emboddied dialogue and responsible action, as Hubert Dreyfus has noted in his analysis of the Internet.

Open Dialogue Code

I originally wrote this entry on September 19, 2004 and published it on

It's funny how certain corporate strategists pay more detailed attention to the press than to their own corporate purpose. (Some may even believe that all their problems stem from bad press.)

So, now we read in the reports (Reuters and the WSJ) that Microsoft has decided to open source its Office software to certain governments and under certain conditions. The same reports say that Microsoft has apparently done this to combat the advances of Linux, its "open-source" desk-top OS rival.

Under the program, Microsoft doesn't completely lift the veil. Governments are able to see 90% of the source code. The bulk of the rest is code where a third party owns the copyright, according to Microsoft. The company also holds back from exposing code that relates to antipiracy technology.
(The WSJ, Sept. 20, 2004)

Even if source code is to be shared with more governments and under much less strict conditions, the strategic threat that Microsoft faces will persist. The problem is not an inability to see the code but an inability to participate in the dialog that ends up in it.

As I've said earlier, what matters is not openness of the source (whatever that means) but the openness of the dialogue about the source code, its use and evolution.

And here is another question worth thinking about. Would government regulations around the world ask for "open-source" code or "open-dialog" code? Most probably, it would be the former because "open-source" is a property more measurable.