Can-IT PLC --> Scatterlogic

Prologue: Arguments, Can-IT PLC

Once upon a time, Bad Managers had a fairly active mailing list called Bad Manager Arguments. It was frequented by many like-minded individuals, long-suffering technical staff who each had (or had a friend who had) a crap manager or two with which to contend.

At the time, John was working for a company called Can-IT PLC, an American catalogue company that loved to can projects. John was employed in the UK "satellite" branch (he had been very excited on first hearing that he would be in a satellite branch, as he had never experienced zero-G before, but was disappointed to find out that this was just a remarkably dull office in a business estate near Watford, just off the M25).

The UK satellite was forever under threat of closure, not for any particular reason, just that its American owners loved to close things. If they were ever to run out of projects to can, they would swiftly start gnawing on their satellites (sounds painful).

Luckily, there were always projects to can, as they also loved to start projects up, without a thought for the viability (business, technical or otherwise) of whatever new venture they were enthusiastically bubbling up in their giggly little think-tanks.

But that's really all that can be said about Can-IT PLC. Well okay, there is more that could be said about them, but as an ex-Can-IT PLC employee myself, I feel it my duty to can their write-up without further ado (and certainly without further explanation!)

Yikes, just goes to prove - if you hang around bad managers for long enough, you inevitably show signs of becoming one. Resist the urge!!

First Days at Scatterlogic

To resume our other little thread (yes there was one), at around the time when the Bad Managers mailing list was active, John left Can-IT PLC, and went to work for a start-up technology company called Scatterlogic Ltd. He was rapturous that (as far as he could tell) he had finally, really, found a company that was run by like-minded people - delivery-oriented, with a genuine excitement for technology, and (hurrah) where the employees were all given share options. Okay, so that last one was a bit mercenary, but in a country where most software companies seem to be run by people who hate what they're doing, Scatterlogic's overall enthusiasm, and loyalty to its employees, was a breath of fresh air for John.

In fact he was so excited at this new-found Heaven on Earth, that he told the people on the Bad Managers mailing list (sorry, instructed me to tell them) that he was like a pig in mud, and had finally discovered a company that he thought was sufficiently sane and businesslike (and yet quite fun at the same time) to keep him happy. In short, the Bad Managers storyline had reached an exultant and satisfactory conclusion.

Of course, it was never going to be as easy as that.

Doin' it Gorilla Style

Just a couple of days after joining, the first warning sign reared its ugly head: Dirk, the company's in-house boisterous American (every British software company appears to have one), insisted on "thrashing out" with John the technical details of John's proposed architecture for his first proof-of-concept project. This was fine with John: the more constructive feedback he could get the better. However, Dirk quickly started to become angry at John's refusal to consider writing the web-server code in Perl (rather than using the much more suitable Java Server Pages). After an hour of going round in circles over this issue, Dirk leapt up and attempted to grab John's head in a playground-style headlock, whilst bending over and pretending to punch him with a swinging fist, drunk gorilla style. Luckily John was able to dodge out of the way, as Dirk had neither the strength nor speed of an intoxicated gorilla, just the lumbering clumsiness.

So John put this initial experience down to bad luck, as the rest of the company appeared to be pretty sound, going by first impressions. Perhaps he was fooling himself, however: he was, after all, the only Java programmer in a company of Visual Basic coders. He began to suspect that he was being viewed as some sort of "harbinger of doom", a potent augury that drastic changes were on the horizon. These frightened individuals had carved out their VB niches, and were quite content to sail their code ship far out into the Proprietary Sea, until there was no sign of land. (Sorry, I think my metaphor gland has just dried up)…

Perhaps if I just tell it how it happened, instead of dressing it up: These people had written an application server in Visual Basic 6, a non-object-oriented language that encourages bad coding styles, and should never, ever, be used to write a server. For a start, it's very difficult to write multi-threaded code in VB (it's certainly impossible to use it to write efficient multi-threaded code). It's a language which came into existence as a "quick and easy" way to produce GUI client programs (note client, not server). No matter how many FTP or SMTP COM components you throw at it, it's still best suited (and only suited) for quickly producing small-scale client GUI applications. Newer versions (Visual Fred maybe?) may one day change that. However VB6 was definitely not the version to do it.

So why did Scatterlogic decide to write their flagship server product in Visual Basic (snicker snicker)? After some careful probing, John discovered the fairly obvious answer: because the company had only employed cheap (mostly imported, i.e. inexpensive) VB coders. All these coders were desperate not to lose their jobs, so would never speak out if they thought something was being approached in the wrong way. Result: nasty, buggy software, produced under panicky conditions.

So, understandably, these VB coders were a tad nervous that their cushy little ruts were going to be dug up, and that they would have to either learn a new language (in this case Java) or find an entirely new vocation, perhaps digging holes by the side of the road somewhere.

John didn't worry too much about these other employees: he had been brought in to pioneer a "new start" for the company, and to gradually build up a Java code-base. The company's development manager openly described Java as a "necessary evil", something that he "hated, but would probably have to live with". So most of the enthusiasm had to come from John. He didn't mind though: he was sufficiently independent to run his own project, and was glad not to have to get involved with the development of the VB projects. In fact he only really spoke to the other programmers socially, very rarely to do with work things.

Increased Company Morale Through Great Policies and Directives

Just like BodgeCo, ten years previously, Scatterlogic apparently had its own set of unwritten rules and objectives. The crazy thing was, its employees appeared to thrive on these values. Only John's morale was in any way decimated:

• No documentation must be put together in any way, shape or form. If a forthright and right-minded Java employee should purport to introduce specifications, then the move shall be treated with scorn and derision for the first six months, then (when it seems that the company cannot plunge any further into the pits of headless-chicken-like anarchy and confusion), the company management shall suddenly embrace the idea with such energetic passion and boundless enthusiasm that the process is doomed to failure anyway. Everything shall be documented!
• All bullet points shall generally try to be a bit shorter than that last one.
• In producing functional specifications, there shall be as many pointless and frustrating arguments as possible, to establish the tiniest of terminology-related trivia. For example, the two development managers may get the entire team of twenty developers into a room together, then forget where they are and argue heatedly between the two of them for at least three hours about the precise meaning of the word "requirements".
• In gathering all developers into one small, unventilated room together, as outlined in the previous point, all developers (except one) shall have eaten curry the previous evening, and shall proceed to stifle the air with silent, but oh so deadly, noxious fumes.
• All VB developers must exhibit a vague interest and desire to learn Java, but shall be too pathetic to actually do anything about it of their own volition.

Fledgling Software Testers

A couple of months later, John's first project was more or less complete. He had handed his first build over to the fledgling QA department (two junior testers, at the time), and shown them how to install the web server, get it up and running, configure the database connections etc. He also took them through the tests they would need to perform. In retrospect, their silent nodding heads and slightly despairing eyes should have struck him as a warning sign.

Soon their bug reports started to appear, thin and slow: reports like "Some of the colours are a different shade when viewed in Netscape instead of Internet Explorer", and "Some of the button sizes are slightly different". These would have been fine if they had also been finding some "real" bugs, but as it was, these testers were being surprisingly ineffective. John would love to think that this was because there were no bugs to be found, but every system has some bugs, at least at first…

John's personal favourite was: "On the login page, no scroll bar appears so I cannot scroll down." This was logged as a Priority 1 (urgent showstopper, immediate fix required). Slightly concerned, he asked the tester to show him what he meant. The page in question did not have a scroll bar simply because it fitted neatly into the browser window! Trying his best to be patient, John demonstrated that if you resize the browser window so it's smaller than the page being viewed, then hey presto! the scroll bar magically appears. The tester was genuinely impressed.

Meanwhile, the VB team's project was also due for completion, but had hit an iceberg in its proprietary sea: the code was horrible, and absolutely riddled with bugs. It was also one week over its "unmissable" deadline. With this in mind, the coders were instructed to work "all hours" until everything was fixed and the codebase was "rock solid". This advanced bug-fixing process involved getting the pizzas in, staring bleary-eyed at the screen until 4am each morning, bashing their tired heads to try and coax out at least some form of coherent thought. Meanwhile, the project manager scowled at the team each morning, and the development manager howled in despair.

In this professional quality, delivery-oriented environment, with scared, panicked developers stabbing their keyboards in bug-eyed desperation, the error rates soared. Version control became a joke, and bug-fixes (themselves pretty flaky and dubious) were overwritten at random by newly hacked patches and so-called fixes.

Yes, John was glad he was not involved in this debacle. It became an interesting, if frustrating, circus to observe from the safe distance of his one-man Java department, over by the window…

Dabbling With the Dodgy

Several weeks after the unmissable deadline, the error rate was still accelerating, and showed no sign of slowing down. Looking very shy, the project manager approached John and asked him if he might, possibly, by any chance, be able to help them sort out some of these VB bugs. As John's own project was long since complete, and he was only about to start his next one, he agreed to pitch in and help out. The sheer horror of that horrible, horrible, hacked-out code was enough to give him bad dreams. He soon realised that this project really was beyond help. It was the most fragile, amateurish, hacked-about server code he had ever seen! He tried to explain this to the project manager, but this did not go down at all well. He was told to think positively, and just to keep on trying.

Realistically, he realised that the only way forward, if there was one, would be to try and instil some good programming practices into these lunatics. He took them through some of their programs, and demonstrated to them how they should have been written, then gently tried to encourage them to proceed in the same way. Surprisingly, they seemed quite receptive to this approach, but (it soon became apparent) they were just doing their nodding-silently act, and meanwhile just carried on in their accustomed cowboyish ways.

Several months later, with still no sign of a working, non-crashing product, and with salespeople clamouring for something, anything to be released, it was decided that enough was enough. They simply released the product. There was a product launch party (great management! Awards should have been given!), and the programmers were each given a "Mission Complete!" T-shirt. As with most failed projects, wishful thinking won them through, and to this day the programmers involved really believe that they did a good job, and released a great product.

After the product release, all the programmers participated in a "mission debriefing", in which they were taken through the highs and lows, and lows, of the project. It was acknowledged that they had suffered from a "lack of experience". Lack of sentience, more like. In particular, they acknowledged that they had not had any form of documentation: no hymn sheet from which to work. Yes, they decided: that must have been the root cause of the problem. Sure, having no specifications is itself unforgivable, but guys! Wake up to it - that wasn't the root cause of the problem...

The Relaunch

Meanwhile, the company's sales people and higher echelons of management were painfully aware that the company did not have any real customers, notwithstanding the one or two "token" clients that the desperate sales team had sold their grannies (at a loss) to get.

Whether this lack of customers was due to the sales peoples' ineptitude, or just the lack of any quality product, is still unclear. It's probably both. Nevertheless, the managers decided that the real reason was that the company did not have the right name. And so, with a massively expensive product launch that hardly any journalists bothered to attend, out of the ashes of Scatterlogic, The Hype Machine was born, and continues to this day, scudding along on its big pink cloud of hype and hyperbole.

>> Next Chapter: Scatterlogic/Hype Machine Part Two

<< Back to True Stories