Twenty five years ago, when Steve W. worked for a military subcontractor, he'd often roll his eyes when meetings were denoted "CONFIDENTIAL". It's not that he didn't take confidentiality seriously, it's just that everything they did was confidential. By labeling most everything "CONFIDENTIAL", there was no way of knowing when some things – like performance reviews and should-we-fire-so-and-so discussions – were really, really confidential. At least, not until you were actually in the meeting.

At one meeting, it was was really, really confidential. It was a one-on-one and across the table from Steve sat the Project Manager. These kind of solitary meetings took place either because you're doing something very wrong... or you're getting canned.

"Hey Steve," the project manager started, "I need a fresh set of eyes on a performance problem we've been facing with the EC Unit."

Steve perked up at this. And not just because he wasn't getting fired, but because the EC Unit — EC being short for Electrical Capabilities — was a pretty big deal as of late. It was a "switch" on one of their new automated testing stations with hundreds of relays configurable to variety of electrical ratings: 50 Milliamps at 0.01 Volts, 400 Volts at 200 Amps, you name it. Being about the size of a VW Bug and having a panel of blinking indicator lights which actually meant something, it was an impressive sight... and had an equally impressive budget to boot.

The project manager continued, "it's taking in the neighborhood of eight hours to run through an engineer test script and that is really hurting us on turnaround. If you can crack this nut, you just might be the hero of the project."

A HERO'S WORK

Eagerly, Steve got to work on familiarizing himself with the EC's software. Basically, the idea behind the program was that, as part of a test, the engineer would write a statement like "Apply X amps at Y volts to circuit C with waveform..." and the program would compute the least electrically expensive path.

Developed by the primary contractor, the code weighed in at about 5,000 lines of Pascal and, with a myriad of functions and high math, it was certainaly no picnic. For days, he poured through the logic. After single stepping though the program and creating enough flow charts and flow diagrams to cover two walls, nothing jumped out at him. However, when Steve added a global counter in every function in the application (as there was no profiler available), he hit paydirt.

While most functions were called proportionally to the number of connections to be analyzed, the following worst offending function was called over a billion times.

function eval_strings_are_equal(s1:string[255], s2:string[255]):Integer

    «reasonably efficient string compare function implementation here»
end

The funny thing about that innocent looking function was how the program handled the parameters. Can you see it? No matter what the size of the string data — even as few as two characters — the program would copy two 255 byte sequences to the stack, one byte at a time. Steve found that if he changed the parameter declaration to the *even* number 256, the parameters would be copied to the stack *two* bytes at a time and reduced the runtime by half!

But, was 256 bytes...overkill? Steve looked further and found that the longest strings ever passed would only be 8 bytes long - he reduced the parameter length to match. The end result: an analysis that would ordinarily take an entire business day would be done in a half hour.

No doubt about it - Steve was the man. And better yet, it wasn't even his company's fault: the primary contractor was responsible for that particular module.

AFTERMATH

At their next "CONFIDENTIAL" meeting, the Project Manager started without a word of small talk. "So do you have something for me?"

Steve smirked and nodded, with a smug Yeah, you better believe I do! and handed over the documentation with a very nice "before and after" graph on the first page.

"WOW!" the project manager was shocked, "This is good!...REALLY GOOD!"

Before Steve could even explain how he did it, the project manager jumped in again. "However," he said slowly, "we're going to have to sit on this for now. We can't tell them about this."

Steve shot back a quizzical look as the project manager explained. As it turned out, there was a big political fight going on with the primary contractor about the project. The primary was blaming Steve's company for overall Electrical Capabilities slowness and Steve's company was blaming the hardware supplied by the primary. Not that it really mattered, because there was a planned upgrade to the Electrical Capabilities system that, among other things, promised much higher performance.

"It's only a single line code change," Steve implored, "it would take all of five seconds to explain. Then the users would be up and run-"

"Yeah, yeah," he brushed off, "we'll keep it as our 'ace in the hole' in case they complain about slowness after the upgrade. We'll show 'em that we're not the ones who are causing all the problems."

"But isn't the upgrade several months away?" Steve rhetorically asked, "we can get them to implement it now and save thousands of client man hours in the mean time."

The project manager glared, "you're not going to share the patch information. It's confidential."

As the planned upgrade date came closer and closer, the likelihood of actually upgrading seemed less and less likely. When the date had come and gone, the upgrade project was "put on hold until next quarter". And it stayed on hold for quarter after quarter after quarter.

Five years later, when it came time for budget cuts, the entire Electrical Capabilities project — military personnel and all — was cut for good. Apparently, the auditors weren't too thrilled that engineers just sat around all day, waiting for some program to run.

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