Telecommunications manufacturing is a cut-throat business. Features, functionality and hardware need to be added and continuously improved at a frenetic pace in order to stay one step ahead of the competition. Engineers must constantly increase their skills to leverage the latest advances in technology to design and build the best product possible at the lowest cost. Slip up just a little, and it can be a death knell for your company.

To save costs, Dog and Bone Corporation (DNB) had eased up on their latest-and-greatest push. Budgets shrank. Progress on adding new features slowed. Hardware upgrades failed to happen. Meetings to justify every little thing began to become the main task in everyone's day. Competitors leapfrogged. Interest waned. Unfortunately, this caused their flagship private telephone exchange (DBX) product to start to stagnate and made some of the engineers begin to feel that their skills were getting to be a little out of date. Engineering-eyes began to wander.

In the white hot heat of competition, DNB needed something to revive sales of their flagship DBX. If it happened to persuade some engineers to stay because there was actually something interesting to work on, then so much the better.

Duncan E. was on the team that helped develop one of the new features: an interface to permit an external computer to not only receive notification of telephone activity within the DNB exchange but to control features and behaviour of the exchange itself! Perhaps not particularly astonishing by standards of today, but in 1990 this was cutting-edge stuff. The latest tools were brought in and the team was trained in a suitably advanced formal methodology, so as to be best equipped to produce an excellent product.

Lo and behold, over many long months the team laboured: analysing the requirements, capturing state transition behaviour, and designing the gateway that would provide the magic window into the telephone exchange. When the magic window was switched on, it worked remarkably well - a strong indicator that formal methods were a valuable tool for DNB's future. For once, management had done it correctly; they gave the engineers the tools, training and blessing to do it right, and it worked. The engineers were also quite pleased with their accomplishments.

Then management reverted to their usual meddling and it began. Delete this. Add that. Change this. Then one of them mentioned that they had read an article about hackers and software piracy.

The DNB management team was worried that nasty software copying thieves would come and take the program from them, stealing all the hard work and effort that the development team had poured into this paragon of software. They wanted their investment in the program to be protected. Period.

And so it was decreed that a dongle would be added. Without this dongle the software would not run. Without this dongle the software would be without worth. Without this dongle, there would be no way to control the DBX. Software would run amok. Skynet would arise. Empires would crumble. And horror of horrors, phone calls might even be rerouted so that only robo-telemarketing calls could be received.

It was Duncan who implemented the dongle code. He took great pains to insert a macro to do the dongle checking rather than using a function call (so as to make it harder for software pirates to hack the dongle-present check).

It was also Duncan who realized that the dongle was an effort in futility, although he left before he told anyone. After all, the software wouldn't run without a DBX to talk to, making the telephone exchange itself the biggest dongle in the world.

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