Picture this. A completely empty room. Now picture this. A large pile of candy — a crapton to be exact — in the middle of the room and the door creaking open to reveal a class of hungry preschoolers, drooling over the goodies. And, as they walk through the door, each of them are given a sippy cup full of Red Bull.

That's basically how the electrical engineers and CAD designers were acting at the Fortune 500 hardware company where Jack works. Since the sales guy from EE-Graphix came in touting the features of their PCB Designer Enterprise Edition 2009 — and brought with them a pile of Krispy Kreme and Starbucks — the engineers and designers were bouncing off the walls. But it wasn't just sugar and caffeine that was making them jittery; they were experiencing a "feature high".

As a whole, they were already relatively satisfied users of the 2005 edition of the software. It worked and wasn't a source of all that much frustration. But the new version had bells and whistles they were salivating for. Aero-style interface... improved Vista compatibility... improved sub-menu item spelling... fewer registry conflicts... you name it! But all that paled in comparison to the big news: the software now had a "concurrent engineering" feature.

Who's Got the Server?

In a nutshell, concurrent engineering promised that multiple users could all work the same PCB project at the same time. This meant no longer having to wait until the project was "unlocked" on the file server before another designer could add their changes. And everyone seemed to love it: management was thrilled at the potential for gains in productivity; users in Austin were raptured at the prospect of not having to ask the admin in Cleveland to cancel the editing lock of another user who left on vacation; and the admin in Cleveland looked forward to not being bugged all the time.

Once the big install day came, everybody marveled that whole teams could be working on aspects of the same project. It was wall-to-wall sunshine and candy canes throughout the whole day. Everyone was content... that is, until the early bird users left for the day.

It turned out that the first user who would open a PCB project from the share drive become the "server". Anyone else who subsequently opened the project became the "client". Because this was transparent, no one even noticed — that is, until the "server" undocked his laptop to leave for the day. All the "clients" who were in the midst of making changes were then greeted with an cryptic "ERR-83105: CANNOT COMMUNICATE WITH SERVER PROCESS ON \\LPTOP4454". And the double whammy that, unless the designer wanted to discard their uncommitted work, they couldn't edit any projects until the next day when whoever owned "LPTOP4454" came into the office and fired up their PCB Designer Enterprise Edition 2009. The icing on the cake? The software offered no hint or suggestion as to whether it's in "server" or "client" mode.

Now, one might think that this would raise a firestorm of complaints, but with the users being such fans of their shiny new software, they were willing to put up with the 'workaround' that the vendor supplied: Start up Windows Task Manager, look for a process named PCBDsgnSrver, and if you have it, send an email / shout aloud / build a small signal fire to let everyone know that you are the server.

This bliss continued for a time... until the fateful day when the Seattle office was added to list of users.

The Magic Cookie

Jack's company had several major design centers across the U.S. and sometimes, they would reuse portions of each other PCB projects between the sites or use the files for training purposes. To accomplish this without stepping on each other’s toes, the infrastructure group set the privileges on the CAD file servers to be read-only. As a result, designers could copy the file to their hard drive and play with it to their heart's content without fear of disrupting a production PCB project in another office.

As it turns out though, if someone at the remote site were to copy a PCB project directly from the server while a user at another site was working on it, rather than open it via the normal channels, a magic cookie file would get copied too. This cookie file is created by the first user to open the project so that everyone else who opens the file afterwards knows that a) they are clients to the server and b) where the server is.

When the local copy is opened, the designer tool will find the cookie, configure itself as a "client", and send edits directly to the "server”. The whole read-only security thing gets thrown by the wayside and any haphazard edits made on the "local" copy will appear as part of the remote project.

You can imagine Jack's frustration in explaining to the CAD designers that they are actually editing a production copy of the PCB project at a remote site, even though (1) the CAD designer copied it to their local C-drive, (2) the CAD designer started the CAD tool by double-clicking a file on their local C-drive, and (3) the CAD designer does not have write privileges to the remote server.

Now that's concurrent engineering.

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