Any communication needs to have at least two ends – the origin and the destination. Most communication – at least the serious ones – are vectors. That is, they have a defined direction in which the information flow is intended. A whole stream of communication can be broken down into multiple vectors to study the communication pattern. However, no amount of communication can be successful if the origin and the destination do not follow an uniform communication protocol (that is why you won’t get far with your English in the city of Madrid). It is interesting to note how the origin and the destination respectively adjusts to arrive at either creating or at least translating to a common protocol (like I learn to say”¿Dónde está la estación?” in Madrid when I am lost near the train station).
Power plugs have always been a bane for travelers. A simple communication between a device and a power source had to be adjusted virtually for every continent and often for every country in a continent. The sheer magnitude of the problem created solutions that acted as translators – like universal power adapters. It took ages for either the origin (plugs) to arrive at a common standard or destinations (sockets) to be able to accommodate several. It is only recently that sockets in India can accept flat pins as well but no such luck at the origin end. Throw the matter of different voltages that go with powered devices and the situation becomes more complicated.
Software engineering is no different. The origin (product managers) have always struggled (and vice versa) to communicate effectively with the destination (engineers). Translators have emerged that try to engineer requirements from origin to a “destination friendly” language. UML for example. The translation layer added its own complexity since it was not natural to the communication process. This created another set of tool that helped in creating UML diagrams (translating the translation). And then engineers had to decode the UMLs (almost akin to modern historians dicepgering hieroglyphics). All because business and engineering could not establish a common communications protocol of stating and understanding what the other is saying.
So who should yield – the origin or the destination? The answer is, neither should have to, if the system is such set (remember – the ancient Egyptians did not have hieroglyphics to English translators because the system was setup such that everyone understood hieroglyphics). The lesson for the business is to keep product management and engineering as separate organizations but have them function joined absolutely at the hips. In my experience a requirement walk through that takes one day is far more effective than a five pound UML document that takes twenty to create and another ten to understand.
Technorati Tags: Communication, UML, Software Requirements, Communication Breakdown, Communication Protocol