Aspects of Paradigm Shift

My friend Daniel recently posted regarding Paradigm Shift.
This made me thinking about the different aspects of a paradigm shift.
First there is the technical aspect. If it is a system then the technical aspect will be apparent in its architecture. If it is a science then the technical aspect will be apparent in the current theories.
But, there are more aspects. The most important aspect is the people. Both the system architecture and the theories of a science can't change their paradigm if the state of mind of the people working on them is not changed. Even if there are objectively compelling reasons for the paradigm shift, if the people have not changed their mind it won't happen.

Since it is very hard to prove the need for a paradigm shift, we are left with politics. Whoever is more politically strong will decide if we need a paradigm shift and to which direction.

Khen Ofek

Engaging communities against Linux and OpenOffice.org

I like paradoxes. Paradoxes of all kinds always facinate me. They enforce you to think and often reveal deep understanding on how things work. You can read my analysis of the Paradox of the Cloud in an earlier post.
This is why I was amused to read Glyn Moody's blog post about a Microsoft's job description.
Microsoft wanted to recruit somebody to fill the “Linux and Open Office Compete Lead, US Subsidiary (CSI Lead)”. Glyn was concentrating on what CSI job description meant for OpenOffice.org. But, I want to stress here the paradox that is apparently inherent in how Microsoft treats the Open Source community.
According to Moody's blog post the job ad contains the following words: "The core mission of CSI is to win share against Linux and OpenOffice.org by designing and driving marketing programs, changing perceptions, engaging with Open Source communities and organizations, and drive internal readiness on how to compete with Commercial Linux and participate with Open Source Communities."
What caught my eye is the paradox of "win share against Linux and OpenOffice.org by ... engaging with Open Source communities and participate in Open Source Communities". Linux and OpenOffice.org are Open Source communities, among other things. So, how can Microsoft engage and participate with Open Source communities and act against them?
I think this paradox is not coincidental. Microsoft's engagement with Open Source communities is not aimed for the better of Open Source, but for the better of Microsoft against Open Source. It doesn't have to be like that, just look at the engagement of RedHat and IBM in Open Source communities and you can see that a good engagement is not against something but for something.
The only one that can solve this paradox is Micrsoft itself, and until that happens, Open Source communities should not trust Microsoft.

Khen Ofek

Subscription By Email

I added the option to subscribe my blog by Email (using FeedBurner).
Please subscribe your mail so you can get an Email notification when I post

Khen Ofek

Symmetry in Software

Symmetry is a powerful concept in mathematics and physics. It is used to analyze and construct elegant theories. Take for example the Supersymmetry theories in particle physics. They provide an elegant way to describe the zoo of particles.

The abstract definition of symmetry deals with the notion of invariance. When an entity has a property which is invariant under certain transformation we say that this entity is symmetric under the transformation. The most famous symmetries in mathematics are present in geometry. In geometry we find geometrical figures which exhibit various kinds of symmetries. Those geometrical figures are often said to be esthetic or elegant because of their symmetries. Symmetry in general is part of being beautiful.
The first time I heard about symmetry in connection with software was several years ago when I went to hear a lecture by Jim Coplien. His lecture talked about symmetry and symmtery breaking in SW.

Since symmtery is such an abstract concept in mathematics, it can be applied in many ways to SW. One of the most effective ways of using symmtery is doing a refactoring. When you are doing a refactoring you want to change the structure of the SW while leaving the functionality invariant. That is, the SW should be functionaly symmteric under the restructuring transformation.

Another application of symmtery can be found in the Object Oriented concept of polimorphism. When we use polimorphic elements, either compile time polimorphism or run-time polimorphism, we are counting on the fact that the actual code should be invariant when we change the element to one of its polimorphic instances. That is, the code is symmteric under the transformation of replacing the polimorphic elements.

Yet another, quite trivial, example is comments in the code. We can say that the funcionality of a code is symmteric under the transformation of changing the comments.

I said that symmtery can often be connected to elegancy and beauty. We can find elegance and beauty in a good SW design and symmtery is often used in elegant design. We can even appreciate the symmtery using our sense of visual beauty when we describe the design using diagrams. The same design can be percieved more elegant if it is presented in a symmteric diagram than if it is presented in a chaotic diagram.

If you have more examples for symmtery in SW you are welcome to write about them in the comments. I will further post symmtery examples whenever I come across interesting examples.

Khen Ofek