In my previous article, I discussed the idea of polymorphism. This idea of “taking many forms” was contextualized into the ability of things, people, and organizations to use generalized frameworks. To close this series, I want to talk about another facet of polymorphic behavior, namely that of dynamic dispatch. In programming terms, dynamic dispatch is the ability for an object to make “smart” decisions about what to do when it's asked to do something. That is, the object itself “knows” a list of procedures that it can undertake. Some of those procedures might be peculiar to just that object, but a good number of them are inherited from more generalized precursors to the object. In any case, you ask the object to take an action, at which point the object goes looking for an action that matches your request. If the object finds a matching action, it executes the action appropriately.
- For the purposes of illustration, let's say that I've created virtual representations of two EQ controls. One is the generalized form, which allows positive or negative gain (boosting or cutting) within a range of plus-or-minus 15 dB. The more specific form is an asymmetric design meant to keep less experienced end-users out of trouble – it only allows for 6 dB of positive gain, while still allowing for the full 15 dB of cut. Where dynamic dispatch comes in is that both EQ objects have methods called “setGain.” However, the asymmetric-gain EQ has a different implementation of “setGain” than the symmetric one. When a control invokes “setGain” on the asymmetric object, the object itself goes looking to see if it has its own version of “setGain.” Indeed, it finds its implementation of “setGain,” which has been crafted so that a request for gain that is greater than +6 is simply restricted – or clamped, if you prefer – to +6. If we were using the symmetric-gain EQ, it would find its own “setGain” implementation, which would only clamp at +15.
- If the above paragraph began to dissolve into gibberish at some point, that's quite all right. The main takeaway is that both EQ gains knew the right things to do in and of themselves. The power here is that the end-user interface isn't burdened with having to know how the gain setting method works for the EQ. Rather, the interface only has to know how to ask for that operation. The interface doesn't have to be totally redesigned for each EQ type. The same virtual fader can be connected to each kind of EQ control, because when that fader asks to set the gain for the EQ, the EQ knows what is and isn't appropriate. (Of course, there should be some sort of indication to the user that a maximum control-range has been reached. That's just good interface design. However, that's beyond the scope of this discussion.)
- “Yeah,” you may be saying. “So, what? We don't do software development in my shop. We install tons of things that use software, but that's about it. Does this actually mean anything to me?” Indeed, it does mean something to you, it's just that the meaning first comes in the form of a question:
- “Do you trust your lieutenants?”
- In the world of brick, mortar, flesh, and bone, dynamic dispatch really is all about trust, training, and understanding. If a person knows what they are supposed to do when they are asked to do it, then they can be effectively delegated to. They are presented with a task to execute or a problem to solve, and they can internally decide the appropriate way to arrive at a desired resolution. The interesting thing about dynamic dispatch in the real world is that it not only precludes a need for micro-management, but also is prevented by micro-management. If someone with authority to delegate is unable to trust someone else to know or figure out a proper procedure, then the whole thing falls flat.
- Sometimes, a lack of trust is a problem residing in the person with authority to delegate. There are plenty of people in the world who just have to get their hands on every little detail. They can't leave anything to the decisions of someone being delegated to. On the other hand, you can also find plenty of people out there who have to be led by the hand through everything. This is normal when a person is still communicating necessary knowledge, but a persistent inability to self-direct through an assigned task is an indication of a deeper problem. Some folks just can't make sizable decisions on their own.
- The good news is that you can often fix the trust issue with training. If people know their jobs, and know that others know their jobs, then trust is easy to establish. If a need to micro-manage or a need to be micro-managed is a personality trait, then that's a different matter. However, my opinion is that people who are actually excited about their craft and allowed to become knowledgeable in it will naturally become trustworthy – if they understand how they fit into an organization, of course. A person who wants to be on the team and knows their part simply does not require hand-holding. All you have to say is “I need this to happen,” and they will figure out the rest.
- Another very neat thing about dynamic dispatch is that, like my “virtual EQ fader” example, the delegating authority does not need to know every little detail about what's being done by the one being delegated to. I'm not suggesting for one second that one who delegates be ignorant. The best leaders are the ones who are passionate about what actually and specifically goes into the business that they are in. What I am saying, though, is that not having to know everything removes a potentially crippling burden from a delegating authority. They don't have to know everything that the guys and gals down in lighting control know. Instead, the delegating authority can spend their time much more effectively. They can make sure that the guys down in lighting control are getting to know what lighting control guys need to know. Since those guys know what they need to know (and, even better, know what they need to learn to know what they need to know), the delegating authority can then put their attention into coordinating the projects that make use of those knowledgeable people.
- In the end, this all connects back to polymorphism because of how a good structure of trust and knowledge supports its own weight. Ultimately, no matter what a project entails, all it takes is for someone to say, “We've got this project, and we need to get it done by this date for this much money.” At that point, the “do this project” method has been called on the shop, and if dynamic dispatch is really working well, everyone in the shop will internally know how to proceed. A cascade of methods will be invoked with the right order and hierarchy, and the project will get done.
