Category Archives: IT

Information Technology

The School of Misdirection

* Masquerade *

“If you have knowledge, let others light their candles in it.”
– Margaret Fuller

“Misinformation works.”
– Rand Paul

Before I became a computer programmer I was a student at a tech school. It was a fast-paced track that promised to teach employable programming skills in under a year.

On the first day the students in my class were also promised that many of us would drop out. That is what had always happened on this tough track.

But it didn’t happen to us.

The stereotype of introverted computer geeks hadn’t taken hold in the culture yet. Sociability was fairly high in the class and many of us hung out together, had lunch together, or had drinks together after class. We studied together. This group was very open, no one was excluded.

Along with a few others I was getting straight A’s and would help anyone who asked, answer anyone’s questions, keep trying to explain for as long as needed. We learned very quickly that doing this helped us to learn the material better. Things become clearer when you think them through and make them simpler.

Helping other students definitely helped me to improve.

And talking about the material made everything more interesting and studying was actually fun.

At graduation time they told us that we were the biggest class to make it through the course and we had the highest class GPA. We had a record number of students finish with an A average and few or no dropouts.

My class had gelled around a sense of mutual support.

Recently I’ve been told that some educational tracks are cut-throat. The students compete with each other for grades and ranking and the tactics can be vicious. A few weeks ago a United States Senator advised medical students to sabotage each other with bad information. Apparently within some fields of study knowledge is a zero-sum game and the incentives reward hoarding it for oneself and trying to prevent others from accessing it.

A few years after graduation I was looking for a better job. One of the students from my programming class spotted my resume on her boss’s desk. She told him that she remembered me from that class and that I’d helped her with the coursework.

I got the job.

In my career since then I’ve always tried to share whatever knowledge I have and tried to help and answer questions and offer ideas. In my spare time I became involved with a local technical group dedicated to spreading know-how and networking, and I served on the board of directors. Sharing has always enriched my life and I love it when I can make something clear enough that I can actually see the light in another person’s face as connections are clicking together.

Occasionally I’ve also encountered people who hoard knowledge or even are outright saboteurs, intentionally giving bad information in an attempt to cause the other person to fail.

I’ve found that people remember the ones who helped them and learn to distrust saboteurs.

As the use of social media rises, employers are catching on to the value of teamwork and sharing. Knowledge hoarders will find that they must learn to share or they won’t fit in.

And saboteurs? Saboteurs will find that misinformation will follow them.

Image:
Masquerade * by pareeerica, on Flickr

Advertisements

Security through Obscurity

20120223-085142.jpg

There was a time when computer programmers on IBM’s midrange platform joked about “security through obscurity.” The data and programs were safe mainly because so few people knew how to get into them. Even if a hacker found a way to connect, the platform architecture was unique and the boxes were priced out of reach for the hacker demographic, preventing experimentation.

The low-hanging fruit for the hackers was on a different platform, machines running Microsoft’s Windows. They knew those machines well enough.

And so programmers didn’t worry as much about security on the IBM midrange machines as the programmers on other, better-known machines did. The lack of public knowledge served for purposes of security and virus prevention.

There was a downside to obscurity though. The midrange programmers watched as sales of their machine stagnated and companies switched to the more popular Windows based systems in spite of security concerns. The job market for midrange programmers shrank and wages fell.

Obscurity turned out to be just another word for unpopular.

Image: “Cavern carved by the sea in an ice wall near Commonwealth Bay, 1911-1914”
Source: State Library of New South Wales

My Basement Monster

The pipes in the house were bumping and thumping and making all kinds of scary noise. It sounded like a monster was chained in the basement, trying to escape. That turned out to be a fairly apt metaphor too.

I spent hours trying to bleed the air out of my boiler heating system. The air wasn’t even supposed to be in there. I’d had a special bleeder valve added to the system awhile back so that air would automatically escape. Yet there the air was.

More alarming than the noise was the monster’s breath. Sporadically, steam hissed out of the bleeder valve in a menacing blast.

It puzzled my furnace guy. He never saw the steam but he didn’t doubt me. He thought that the air in the boiler water was a sign that the bleeder valve wasn’t working anymore but he couldn’t explain how it still allowed steam to escape.

He showed me how to bleed the system manually. It was a time consuming process involving water trickling through a hose into a bucket, watching bubbles of air escape. The procedure was complete when there were no more bubbles.

The noise you’re hearing is just air in the system, he told me. Get the air out and you’ll be fine.

He promised to check on the cost of replacing the bleeder valve. It was solid brass. The metal had become very costly lately.

I trickled out bucket after bucket, watching air bubbles rise. They were endless.

The noise continued. Once or twice a day I caught the monster breathing steam again. I’d been warned that the boiler could crack if there was too much steam. That would mean a whole new furnace. I cut the power to the boiler and kept on bleeding it.

The bubbles were endless.

The house got cold.

I turned the boiler power back on. I kept burping the monster.

The bubbles were endless.

At one point the controller box began to hum loudly, so loudly that I was afraid it was some kind of alarm. I swatted it with my hand. It stopped humming.

Ah, percussion maintenance works again, I thought.

The next morning I found that the boiler no longer responded to the thermostat.

I told all of this to the furnace guy.

Keep bleeding, he said.

It was getting cold out and he was handling a lot of calls from his customers, working into the evening day after day. I’d always known him to work this hard. He’d been born into the business that his father had started in 1950 and he’d been running it himself for over a decade.

That night the boiler steamed and thumped with reckless fury.

Turn off the boiler, he said. It could crack. Do you have another heat source? Can you stay warm? You must need a new controller. I can’t get one until the morning.

The controller would be about as expensive to replace as the bleeder valve.

And the furnace guy’s labor and expertise were appropriately costly too.

The next day he showed up with a new pump.

I was talking with some of the guys, he said, and we decided the real problem is that the pump is failing. The heated water isn’t being distributed well through the system. The boiler water is overheating because it doesn’t get far so sits and cooks. That puts air into the system and makes steam.

He swapped out the pump. This part was about half as costly as either of the previously proposed solutions.

The house began to warm again. And it was quiet. The banging stopped. There was no more steam. The controller worked again. The monster morphed back into a quiet house helper.

I’m grateful that my furnace guy listened to my description of what was happening. The boiler neither thumped nor steamed while he was present, just meekly kicked in. Except for the bubbles in the system, everything had seemed to be working.

His listening skills had paid off.

I’m grateful that he kept thinking and didn’t just charge into the first solution that presented itself, or the second.

Both solutions would have been expensive and neither would have fixed the problem.

His years of experience with problem solving had paid off.

I’m grateful that he’d shared the problem with others in his field and considered their ideas.

His professional network had paid off.

The most valuable component of the service he’d provided wasn’t a new pump, it was himself.

Over the past year I’ve been saddened to hear many people devalue the labor and experience of other workers with no real understanding of the requirements of the fields they deride as overpaid. I pray this type of mass derision and contempt never falls on my furnace guy or the others in his field.

Because as expensive as the labor was for my boiler service, it could have been much worse. There is no basis for expecting omniscience from a problem solver, ever. Human beings are often inventive and clever but no one can truthfully call any of them perfect.

The best and closest substitute for troubleshooting perfection that we can have is a process that includes patience, knowledge, thought and respect.

Those attributes carry a necessary cost but such a process is what the best troubleshooters must rely on if problems are to be actually solved.

Image from Flickr : “fallrod”

Collaborate!

My favorite thing about collaborative software and techniques is the ability to quickly assemble and coordinate an ad-hoc cross-functional remotely diffuse team to work on an urgent or important problem.

Imagine a situation at a manufacturer where a production line has gone down due to the failure of a key computer application. A person in IT is notified by a worker on the line. The collaborative software is used to create a document that describes the problem and a high priority is assigned. The IT worker assigns appropriate troubleshooting resources via the software: maybe a techie to check the hardware, someone to check the network connection, someone to investigate the interface between an in-house written entry program and the ERP packaged software provided by an outside vendor (who might also be tapped for input). Notifications and alarms are issued.

All of these people report back or can ask questions via the collaborative software, keeping a centralized record of progress on these steps.

People on the line are granted access to the problem document as needed and are subscribed to all updates as they occur. They can answer or ask questions. Managers can be subscribed so that they can monitor progress and can easily see which parties are involved and whether the crisis is getting the appropriate attention and resources. People who manage relationships with outside stakeholders – perhaps a customer whose shipment may be delayed or a vendor whose product may be faulty, are included. Anyone who needs to be kept in the loop is easily added.

Troubleshooters can address the entire group instead of playing phone tag with individuals and hoping that information is relayed to the correct parties.

Everyone’s roles and behaviors become easier to discern. I’ve found that the people who have a tendency to disrupt meetings and discourage the input of others with sarcasm or bullying tend to monitor themselves better when their comments are self-documented. These controlling tendencies are visible to all and can be confronted and coached if bad behaviors surface here. This makes it easier for the entire team to focus on the problem at hand, minimizing the interpersonal dynamics or conflicts that might occur in a more private setting.

Individuals who hoard knowledge become more apparent as do the knowledge sharers. Stellar performers can be lauded and thanked right there in front of everyone involved.

The entire process is self-documenting and becomes a source of knowledge should a similar problem occur later. The document can become a repository for evidence: a place to attach PDF copies of reports, emails, affected vendor or customer info, notes, links to similar problems, checklists, etc. It becomes a workspace, lab report, and agenda. If further action is needed to prevent a reoccurrence of the problem, the document becomes an invaluable resource. It formalizes problem solving, notification procedure and evidence retention. Problems are less likely to be band-aided and forgotten. It becomes more possible to trace the root cause of secondary problems that sometimes arise due to the unforeseen consequences of a bad ‘fix’ of the original problem.

The entire process is self-documenting and becomes a source of knowledge should a similar problem occur later.

Integrated with best practices from a discipline such as ITIL, this type of collaboration can reduce the number of critical incidents in an organization, allowing everyone a breather from constant firefighting so that the organization can focus on becoming more competitive and effective, rather than focusing on just keeping the lights on.

20110620-052449.jpg

How a Personality Profile Helped Uncover John Edwards’ Lies

It’s easy for a confident liar to lie. Getting that same liar to tell the truth is another story, a story told by David Perel, former Editor-in-Chief, National Enquirer, in a recent post.

As Perel recalls, no one wanted to take the National Enquirer seriously when it published a piece about the pregnant girlfriend of a married presidential candidate. The man, John Edwards, denied it. Edwards’ aide supported the lie by claiming paternity himself. And with the supermarket tabloid’s long history of reporting ‘news’ about such fantasy figures as Bigfoot or the Loch Ness Monster, displaying photos of Satan’s face in a black cloud, denial was an easy sell for Edwards.

Incredibly, the Enquirer team had not expected the denial or the creative cover story. Edwards was betting that only his confession could validate the unsavory story. He wasn’t about to do it.

Unwilling to write off an actual news story and all of the effort and high-tech resources that getting it entailed, the Enquirer hired a mental health professional to help them to understand why Edwards was lying and how to gain his confession.

The analyst told Perel that Edwards was a man who prioritized and controlled his own carefully constructed image. He would never confess to anything unless it was the only way to keep some of that control. This knowledge changed the way Perel handled the growing evidence.

Perel held most of the evidence back but let Edwards know that the Enquirer team had stalked and photographed him throughout a recent encounter with his mistress. Edwards was given just enough information to realize that the Enquirer’s claims were true. From there his own imagination and guilty conscience could take over. Not knowing what else the Enquirer had, Edwards confessed to the affair but continued to deny fathering a child with his mistress, keeping some small control of the extent of his betrayal.

It was enough to validate the Enquirer. Thousands of man hours and the use of the best technology available had still come down to one thing: understanding Edwards and predicting his reactions.

According to Perel, letting Edwards imagine the worst was the only way to get him to tell some truth.

The way to get unconventional results

The way to get unconventional results is to use unconventional methods. It’s risky but break the mold.

What Year Is It, Anyway?

Suddenly I’m hearing the following question come up:

“Is it Twenty-Ten or Two-Thousand and Ten?”

Is it just me or should the answer be obvious? It’s Twenty-Ten.

No one in the 1900’s described a year as “One Thousand Nine Hundred and Ninety Nine.” No, it was Nineteen plus the two digit year.

Of course, seeing a four digit number as two separate two digit numbers was one factor that led us to the whole Y2K mess.* That’s the power of perspective at work.

Is it too much to hope that we’ve since become wiser and more aware of how language and perspective are intertwined?

But that’s a whole ‘nother topic.

[* For those of you who weren’t business programmers in the nineties and think Y2K was a non-issue, I assure you it was a mess. Not for my long-term clients so much, as my code was Y2K compliant beginning about 1991. But many companies didn’t even to begin to think about it until late in the decade, even though their every business transaction was about to go from nicely organized to a state of scattered disarray. Imagine if search engines like Google shuffled all of your 200,000 + search results. How useful would Google or the web be to you then? Worldwide, business programmers worked really hard to prevent that from happening to your companies, and they succeeded.]

posted to myspace and kkostuck.Wordpress.com 2009.01.31