One of the first news announcements that I received today announced that another major financial institution had been the victim of yet another malfeasance of protecting its customers' personal data. This bank has admitted that four laptops containing the unencrypted personal details of 10,000 customers have been stolen.

The information on the computers includes names, addresses, bank account details and medical records of customers at branches. If that was not bad enough, these PCs were stolen between June and October last year, but the bank has only just reported the theft!

This incidence is only one of what seems to be a non-ending stream of problems in the areas of privacy and security in the Transaction Processing Industry. And that is why we at TPAtlanta have to periodically use this space as a reminder for all us to be more prudent and to insist that our companies develop the necessary policies and business practices so we do not become fodder for ridicule. Why is this happening over and over? How can we create working environments that foster good IT security practices?

Personally, I think that there is a Great Divide in the realm of information technology. I am not talking about Windows versus Linux or Java versus .NET-no, nothing like that. The gap that I am referring to is between software developers and the people who manage them-what I call hackers and suits.

Let's clarify one thing first: The word hacker is used in at least three senses. There is the Hollywood sense of a kind of "digital burglar" (more properly called a cracker); there is the sense of a person who throws software together quickly and without skill or caution; and finally there is the "true" sense of the word: a craftsman who is a master at what he does, knowledgeable and capable. It is that third sense that I am concerned with here.

And what is a "suit"? Well, if you don't know what one is, you might be one. The term is common (though not universal) slang for a manager-deriving, of course, from the contrast in dress code. In many or most firms, developers are permitted to dress casually. Managers tend to wear suits-in some cases even appearing to enjoy wearing them-and this sometimes puts developers on their guard. But even if you so have to wear a suit in your role as a manager, you probably still think and behave like a suit! First of all, it helps to understand where the hacker is coming from. Software is a strange thing-it is abstract and malleable since it is written in some kind of language-but it is also like a machine in that it has to be precisely correct and has to function properly. Software development is a hard skill to acquire, and mastering it often gives the practitioner a kind of tunnel vision. The hacker may worry about many aspects of his code, such as readability, portability, maintainability and performance; but his code is basically his world.

The average hacker has no business sense. He is not even aware that he lacks one. His world is megabytes and milliseconds, not dollars and cents. He likely has never had a management course-perhaps has never had any kind of business course whatsoever. He evaluates things by their performance and their technical excellence. He may tend to overlook the user; usability and user-friendliness, good online help and good documentation are not usually highest on his list of priorities. Even farther over his horizon is "the bottom line" itself. He is buried so far in the internals that he is unaware of any positive or negative economic impact his actions have.

Let's examine ten tips of how suits and hackers can work better together.

So here is Tip 1: Remind the developer that technical excellence is no guarantee of success. In fact, sometimes they are hardly even correlated. History is littered with examples of superior products that failed for various reasons: bad timing, bad marketing or one crucial design flaw. These range from the Tucker automobile of the 1940s to the BeOS operating system of the 1990s. There is a good reason that betamax is often lowercased and used as a verb. Developers can understand this if they are reminded. Tip 2 is directly related. Point out the economic impact when you can, and be as specific as possible. If a developer wants to slip the schedule by a month to add a feature he considers important, bring money into the equation. Talk about revenue lost to a competitor who reaches market first. Talk about how many sales might be made in that extra month. Ask the developer to evaluate the situation in light of those facts. Of course, he may still disagree; but you're still the manager.

And, of course, disagreements do happen. Either side may be wrong in a given situation. But good two-way communication can mitigate the conflict. If a developer is balking at following your course of action, don't dismiss his opinion immediately-he's a professional in his field just as you are. Don't be a dictator. Tip 3: Explore the developer's specific reasons for disagreeing, because they may be valid. And Tip 4 is the flip side: Explain the constraints and the assumptions you are working under and the reasons for your decisions; if you must overrule a developer's opinion, at least give some justification for it. Communication is the key.

Of course-forgive me for stating the obvious-communication is possible only if the parties speak a common language. And that's often not the case with these two groups. Tip 5: If your company pays for courses and seminars, encourage the developers to do some management-related studies. If you're lucky, that will open their eyes. And likewise-Tip 6-it doesn't hurt you as a manager to do some studying at a more technical level. You can't match the expertise of someone who spends all of his or her time buried in those details-but you can at least try to stay somewhat current. But Tip 7 is very important: Never fake it! Honest ignorance is always better than pretending knowledge.

The larger your company, the more bureaucracy it probably has, and the more "process" or red tape-"administrivia," as some call it. This is the bane of the developer's existence. There are few things a software person hates more than to be pulled away from "real work" to fill out useless forms or to attend seemingly irrelevant meetings where nothing is decided or accomplished. I vividly remember a coworker's comment from years ago. "The product of the process isn't code," he said. "The product of the process is more process."

The process exists for the company, not the company for the process. It is necessary to follow rules and procedures, but don't be a slave to them. Tip 8: Shield your developers from bureaucracy and red tape as much as possible. They will appreciate it, they will respect you more and they will be more productive.

In fact, I would go so far as to say (as Tip 9): Help streamline the process, even help short-circuit it, if it helps productivity. Do all your developers really need to track their time in 15-minute increments? Do they really need to fill out a three-page status report every week, adhering to a rigid template? If these things contribute to the bottom line, then keep them; if not, silently look the other way while these things get shoved to one side.

And Tip 10? Read Dilbert of course. Don't be surprised to see some people you know in that strip: people who work under you, over you, and around you. It's not a real portrayal of corporate life, of course...but it is corporate life held under a magnifying glass. Look past the exaggeration, and you will see reality. Learn from it.

Now, having said all this, what can we conclude? Software developers don't appreciate their managers enough. They have much to learn about the difficulty of "steering" a company and the essential roles that managers perform. But speaking as a manager, I know the reverse is also true: managers often do not appreciate their developers either-the difficulty of their tasks, the expertise they wield, or the constraints they have to deal with.

But my real message is that it does not always have to be this way. The gap can be bridged, and the two groups can work together. So how well does management and the IT staff communicate in your company? Please let us hear from you with your own stories of policies and practices, both good and bad, as we all strive to be more successful in the Transaction Processing Industry.

Calvin D. Johnson, Publisher
publisher@tpatlanta.com
Trans Atlantic Systems, Inc.