Slippery software

Customers will not tolerate a product with poor quality, regardless of the definition of quality. Or will they? Dave Wilson reports.

<b>A customer will not tolerate a product with poor quality, regardless of the definition of quality. – From “201 Principles of Software Development” by Alan M. Davis.</b>

The head of the software engineering department was a strange beast with idiosyncratic habits. Despite the fact that he was an extraordinarily bright chap, his interpersonal skills weren’t up to much. Frankly speaking, he had real trouble dealing with anyone that the senior chaps in the company hired to actually manage him.

Truth is, he was actually unmanageable. Any requests that he received from his boss to work on any undertaking that he deemed to be trivial – like documenting his work or educating other members of his department – were put on the back burner until they were quietly forgotten by everyone.

You might have thought that he would have been ‘let go’ a long time before he was. But his skills were such that, no matter what his behaviour might be, he was always allowed to carry on regardless.

But then lean times came to the company. Despite his software savvy, the head of the software engineering department was let go along with a number of other individuals. And the department was trimmed down to the bare minimum.

Of course, they were all such bright sparks, that they had no trouble at all in finding employment with other manufacturers in the area. The ex-head of the software engineering department, in fact, was lucky enough to gain a more responsible job at an even higher salary with a local software subcontractor no more than five miles from his previous employer.

But things did not look so bright at the company they had left behind. The chaps that remained in the department soon became so disillusioned by their lack of prospects that it wasn’t long before they left too. And, although new folks were hired to take their place, no one really understood the legacy code as well as the fellas that had departed. And the guy that knew it the best, of course, was the previous head of software engineering.

During the course of the next few months, the software engineering department became so unreliable and flaky that other divisions within the company actually started to look elsewhere for quotes before simply passing over new projects to their in house development team as they had done in the past.

And wouldn’t you just know it? One of the divisions even approached the software subcontractor that had hired their previous head of engineering! To add to the hilarity, the subcontractor was actually hired the following month to engineer some software at less than half the cost that the in-house department had quoted.

Now I don’t know how the old head of software felt about this. But if I know him, he probably re-assessed his interpersonal skills in a pub over a few beers the very night the contract with his previous employer was signed. Because as I understand it, he’s now working for a percentage of the profits.