Thursday, February 08, 2007

Importance of System Metaphor

Kent Beck describes System metaphor in his legendary book Extreme Programming : Embrace Change as A Story that everyone in XP team can tell about how the system works.

So? Why do we need one more buzzword? Why should I care about it?

Consider a team working on a large software application; typically work is componentized by the architects and/or managers. Every member works on specific part of the component or on specific component. Few people (Software Heroes) know what is the real picture of the application and how it works or is supposed to work. (As a metaphor, every member in group is holding/attached to parts of an elephant, some one is holding his pillar leg, some one holding tail and few holding trunk and god-sized ear; while no one knows how he looks like and how to sell it! Nawal, thanks!).

The result? Software heroes become the concentration point (High risk :)); lack of shared vision in team leads to communication gaps (Our product can generate application, end-to-end in three different platforms); Everyone in the team has her own (mis)understanding of the application (we're building a modeling tool, no- it's a part of framework; ok, that framework is persistence framework- may be that framework is generated using our tool); frequent suboptimal technical decisions (e.g. selection of specific framework which may not fit well with other's work- we'll code GEF editor, we will generate GEF Editor using GMF); rework/duplication (existence of several similar utilities in different module);

Having worked in such scenario, I realized that lacking shared vision or system metaphor results in chaos (implementation to deployment), countless bad decisions and loss of interest in regular work. Everyone becomes concerned about his/her own work rather then end-product (customer satisfaction) - there is no more a collective ownership. Work becomes chore and no fun :(. We may even lose out good ideas from team which might be real worth. Team becomes just a mixture of testers, coders, analyst and so on(and you'll not mind being called a Java Resource!).

One more thing I love about XP is, it keeps everyone informed of what is going on, which in turns backs feedback cycles. When everyone knows what is going on, they participate in overall effort rather then mere work assignment.

I understood the importance of system metaphor the harder way..

No comments: