Clif Notes: Shut Up and Put Up
As I talk to MultiValue developers about modernizing and evolving their MultiValue applications into this millennium's technologies, I find that the conversations tend to fall into a set of patterns. I may have ten or fifteen conversations with people at the conference about this topic, but each of them usually mention only three or four of the same things. So in the hopes of giving you something to think about and alternate ways to approach the problem, I've identified a couple of these and have some suggestions for a different approach.
Pick your battles
Simply put, this means not to waste a lot of your time and energy fighting battles (discussions, arguments, etc.) that you have very little chance of winning. Your time, energy, and motivation would be better spent elsewhere.
For example, if a seasoned MultiValue developer wants to argue that green screen applications are superior to GUI-based applications, or that users prefer green screen because it allows faster data entry, why are you bothering to waste your time trying to convince them otherwise? They obviously have either not talked with the users, or they have very selective filters of what they hear. Their mind is made up, and nothing you can say, do, or show them is going to change it. Give it up and save yourself the wasted time and irritation. Move on. I rather go play with my granddaughter than waste that time trying to convince someone to give up the ED editor and learn to use an IDE. I'm sure that you have better uses for your time, also.
Stop talking
Another story I frequently hear follows the pattern of the teller trying to be the advocate or evangelist for using a new MultiValued technology — web services, data encryption, that sort of thing. The applicant has tried for months, sometimes years, to persuade people in their shop to at least explore the new capabilities and how they might be used to their advantage. But all of the arguments seem to fall on deaf ears.
Now the reason for that can be many different things. No money, "we've always done fine without it," and "it would take way too much work" are among the most common. I could give you a list of talking points to try to overcome each one of these objections. But I would imagine that if you have been fighting these kind of battles for any length of time, you have come up with your own set of responses. And again, although we might be able to hone our arguments or make them more diplomatic and, we hope, persuasive, why waste our time beating a dead horse with a deaf post?
If all of your presentation of facts, list of advantages, and logic has not persuaded them in the past, what makes you think simply repeating yourself is going to persuade them in the future? When someone has heard all of the arguments, thought about them (however briefly), and made up their mind about something, it is a rare person who will reconsider their position based solely on the same rationale being presented to them over and over. In their minds, they have already dealt with this.
You have probably seen the poster that reads, "Get all the facts; then you can ignore them."
Maybe it is time to just shut up.
Prove it
Now please notice that I said shut up, not give up. But at this stage of the game, you have lost the war with words. There is only one thing left to try — prove it to them. Show it to them. Let them actually see what you're talking about. Demonstrate the concept.
In other words, to twist the common phrase a bit, it is time to "shut up and put up."
Let's say that you have been trying to convince your organization that implementing web services would be a way to make the information in your MultiValue database accessible to your customers. Imagine a simple web page where you could enter an order number. It would then use a web service to get the current order status and display it. You could even use someone else's web service, such as the shipping company, to retrieve and display the tracking information.
It doesn't have to be fancy. Remember you are trying to do a proof of concept demo, not a polished application complete with authentication and all the bells and whistles. All you need to do is code the pieces to demonstrate the technology works. And keep track of how long it took to code and implement. Many people process information visually. They will literally "see" what it is you have been talking about all this time. The fact that you treated it as a lab exercise and tracked your coding and implementation time (subtract the time for the learning curve) gives you a real metric for determining what level of effort (and cost) would be involved. It might not be highly accurate in actually estimating the project, but it is certainly better and more impressive than "piece of cake." All you have to do is learn the technology and your platform's method of implementing it and code the demo.
I can hear your shocked voice. "He just said that all I have to do is… Is he crazy? My boss will never let me do that! There is no way that he is going to let me spend time working on something that he already said "no" to. Surely he's not suggesting that I sneak around behind my boss's back and run my own private skunk works project?"
No. I was not suggesting that. But where did I say that you were supposed to do it on company time or using company resources? Several of the MultiValue vendors have personal editions of their software that you can use for your own skill building and education. Do this on your own time.
Now I will admit, I know a lot of MultiValue developers who absolutely refuse to learn anything new unless somebody else pays them to do it, be it an employer or a customer.
But at some point, at least if you are serious about wanting to see MultiValue grow and thrive, you are going to have to invest some of your own skin in the game. You can't just sit back and continue to whine about how your vendor doesn't do enough advertising, how Spectrum doesn't give everything away for free, or how your VAR doesn't offer classes in the new technologies at no charge. There comes a time when you have to turn off the TV, grab a set of documentation, and put some effort into learning something on your own.
Will your efforts be rewarded back at your place of (current) employment? Maybe. Maybe not. I have had instances where a proof of concept demo completely turned minds and attitudes around. I have had other cases where it didn't make a single bit of difference. But you don't know unless you try.
So if you want to continue to have a career in MultiValue, even if it is only for enough years so you can retire, you need to start showing people what these systems can do. And that probably means skipping a few football games and learning something new.
After all, if you're not that interested in your career, why should anyone else be?
