A large company is something like a whale. They are huge beasts who strain their sustenance (profits) from the ocean that surrounds them. In this analogy, customers are krill, but their employees are more like Jonah- wrapped up inside of a beast larger and more complex than they can possibly imagine.

First, we have no control over who gets swallowed up in that whale with us. Phil, for example, found himself huddled in the bowels of a large manufacturer with Len as his only company.

The Broken Piece

Len, like an RJ45 connector with a broken clip, had a difficult time holding onto his connection to the world around him. This led to bizarre, almost surreal exchanges, like:


Len: Do you do even logging in your programs?
Phil: I… I write to a log.
Len: I’m getting duplicate entries in the log.
Phil: Then you’re probably writing to the log twice.
Len: I was thinking about only writing to the log if the entry ID is even.

Or a later encounter:


Len (pointing at a machine): What’s this?
Phil: It’s an air compressor.
Len: What does it do?
Phil: It compresses air.

In the end, Len deleted all of the .resx files from an ASP.NET application and spent a few days trying to understand why it stopped building.

File(system) Not Found

Tom had a similar issue with fellow developer Reggie. Reggie was getting errors, and Tom suspected that Reggie had an old version of one of the key assemblies. Reggie was unsure how to check that, so Tom gave him instructions- “Right click on the assembly, go to properties, and on the details tab, you’ll see the file version.”

“Where is that in the C# editor?” Reggie asked.

“It’s on the file system.”

Several minutes went by, and Tom assumed Reggie had things under control. “Can you send me a screen shot of how to navigate to that? I’m not able to find the file system.”

Production testing

It’s not just the challenging co-workers though. Sometimes, the environment inside the belly of the whale itself is the challenge. John was getting ready to release some code changes for his company’s largest client. That led to this IM exchange:


(10:59:11) John: The boss says to be sure that this works we need to test it. Is there somewhere I can test this?
(11:01:06) Dave: there’s nowhere to test it
(11:01:10) Dave: it has to work first time

Hey, Four Eyes! Your momma dresses you funny!

When the whale gets big enough, the whale stops thinking of itself as a rampaging Moby Dick, and instead starts thinking about just how much it has invested in itself. Then it starts thinking in terms of risk aversion.

An Anonymous informant sent us a process document from a large banking company. It leads off with this chilling summary:

“Up to and including dismissal”! What is this “4 Eyes Check”, and why could I lose my job over it? Is this a crack about people who wear glasses? Of course not- it’s a fairly common sense policy: if someone’s about to do a manual process, someone else should watch. It sounds like a great way to cut down on errors. A large company, though, can’t simply lay out a policy like that. It needs to be couched correctly.

Because in a process like this, you don’t just have four eyes. You need far more. You need the process owner.

You need the control owner.

Then you need your two pairs of eyes.

You need to keep one foot in reality.

But the other foot needs to document absolutely everything that could possibly be documented.

The list of things that “must be evidenced” is surprisingly short, at only a page long, including things like the script used, the parameters used, the CMDB stated both before and after the process, the names of any files changed, etc.

In addition, we need documentation to prove that our “pairs of eyes” have complied with the “4 Eyes Checking” standard.

And finally, this standard is exactly that- a standard:

There are no exceptions .

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!