There’s a Screwed Scenario that I missed.

Back in my Borland days, we were working hard on Paradox for Windows. I was a QA engineer testing the database creation and modification functionality. My counterpart in engineering, Jerry, was working hard, but getting absolutely nowhere.

We were mid-to-late in a 1.0 product cycle and most of the engineers were slowly moving from development into bug fix mode, but not Jerry, he was still implementing… over and over again. That’s the Screwed Scenario, you’ve given a critical task to someone who is utterly unable to complete it.

Now, let’s first give Jerry a break. He was a fine programmer, but he had two major strikes against him. First, Jerry had never programmed for Windows. so he was learning while he was coding. Second, this was also a 1.0 product. I’ve got an article kicking around my head about 1.0 product development… it’s titled “1.0 spelled One point oh my god I’m never going to see my family again and, dear lord, I’m going to take the company out while I’m at it.” Short version: 1.0 is incredibly hard and combined with his Windows inexperience, Jerry was in trouble.

Yet, Jerry has pride. Jerry believed that he could pull it off, but being on the receiving end of his code, I observed a disturbing coding practice which we’ll call “moving crap around on your plate”. Jerry’s approach to fixing his bugs was to move his code around in interesting ways much the way you used to shove food around on your plate in a feeble attempt to convince your Mom that you actually ate your beets. Nothing substantively changes, it just looks different. Another name for this coding practice might be “Coding by hope”.

The end result with Jerry’s code was each time he’d fix something, we’d discover another fundamental problem with the feature. Yes, small incremental progress was being made with each bug fix, but Jerry was in a losing situation because his basic architecture was crap. When asked for status, his lists of excuses were astonishingly believable. They were the excuses of a person who honestly believed he could pull it off and was willing to put in the hours to do it, but all the hours in the world wasn’t going to help Jerry because he was in over his head.

If you’re the manager in this scenario, you’ve got to make a major change because you can not release crap. There are companies that do this and end up making a tidy profit. You are not that person because once you are rewarded for releasing crap, you begin a blind walk down a path of mediocrity that ends up with you working at Computer Associates on a product no one has heard of and that no one cares about.

It’s a two step fix process. We needed to make a Jerry adjustment and then we needed a miracle. I’ll start with the easy one.

We needed Jerry. He’s the only one who knows what the hell is going on in that pile of spaghetti and he can fix trivial bugs. The engineering manager sat Jerry down and told him we need to focus on quantity. There were scads of trivial little fixes all over the place that had been ignored and Jerry could handle those. Yes, he was pissed, but in a few weeks, Jerry was cranking because people always work better when they know they have the ability to complete a task.

With Jerry adjusted, we had to face another fact, we were six months from shipping and we had a major portion of functionality that was cobbled together and barely working. In this scenario, you need a unique talent. You need a Free Electron.

The Free Electron is the single most productive engineer that you’re ever going to meet. I have not even provided a definition and I’m guessing a person has already popped into your mind that fits the bill.

A Free Electron can do anything when it comes to code. They can write a complete application from scratch, learn a language in a weekend, and, most importantly, they can dive into a tremendous pile of spaghetti code, make sense of it, and actually getting it working. You can build an entire businesses around a Free Electron. They’re that good.

Free Electron Got’chas:

» There are two classes of Free Electrons. Sr. Electrons and Jr. Electrons. Both have similarly productivity yields, but the Senior versions have become politically aware. In technology savvy organizations, most CTOs fall into this category. Think Bill Joy. The Junior versions have all the ability, they just don’t have the experience of dealing with people because they spent a lot of the youth writing their own operating system as a intellectual exercise. These Junior electrons represent the single best hire you can make as a hiring manager. If you get two in twenty years, you’re doing something right.

» Misdirected Free Electron intensity can yield odd results. On one project, I assigned a couple of slippery memory corruption bugs to a Free Electron who nodded quietly and promptly vanished for a week. When he returned, the bugs were fixed and the entire database layer had been rewritten. A piece of code that’d taken two engineers roughly six months to design had been totally redone in seven days. Sound like a great idea until you realize we were working on a small update and did not have the resources or time to test a brand spankin’ new database layer. Oops.

» Free Electrons sometimes will never engage and they’ll never explain why. Free Electrons are high functioning and have a strong opinion about everything… but they may never tell you that opinion. If you’re asking them to do something that they don’t believe in, they aren’t going to do it… ask all you want. The worst case is when you ask a Free Electron to pull of a diving save and they nod in the affirmative and promptly return to whatever they were doing before you distracted them with your useless request One week later, you’re going to be expecting the miracle, but the Free Electron is going to plainly say, “Haven’t got to that”.

One week more, your hair is going to be mostly pulled out, and then you’re going to realize you didn’t need a miracle in the first place and inaction was the right move. Your Free Electron knew that two weeks ago. He/she just didn’t want to take the two hours to draw the picture for you… Annoying, huh? You’ll get over it.

» You might expect Free Electrons to exhibit the personality of other uber-nerds, but often they do not. The main Free Electron at Netscape was the most decent human being I’ve met in recent memory. He also rode a unicycle.

» There are two primary tasks in an engineering organization. Research and Development. While the Free Electron is imminently capable of doing the development, their value in the organization is research. They define the bleeding edge. If you leave a Free Electron in the development role too long, they will vanish and you will have permanently damage the future productivity of your organization.

Back to Jerry.

Enter Bernard, Borland’s resident Free Electron. Up until he started poking around the code, I had no idea what Bernard actually did. He had a office. It was full of books. He talked a lot and produced little visible work. “Blowhard” is what I thought.

Bernard started tinkering with Jerry’s code on a Friday afternoon. The next Monday, I was able to run through my functional test matrix for the first time ever. By the end of that week, Bernard had closed a majority of the high severity bugs and was beginning to tread in fix areas reserved for Jerry. The following week I was racing to file bugs to keep Bernard engaged.

That is a Free Electron at work.