Software Reality
Programming with
a dose of satire.

Site Map Search


Agile Development
 
Extreme Programming
 
Code Generation


True Stories
Latest Stories
Archive
Your Stories

Submit Your Story
Contribute your own workplace story to our message forum...

Check out our ageing Reviews Section


Use Case Driven
Use Case Driven Object Modeling with UML: Theory and Practice
Get from use cases to working, maintainable source code. Examples use Spring Framework, JUnit and Enterprise Architect

Agile UML
Agile Development with ICONIX Process
A practical subset of agile development techniques, illustrated by example

Get Controversial!
Extreme Programming Refactored
Extreme Programming with a dose of satire
Available now:



True Stories - BodgeCo and Friends

<< Scatterlogic Part One

The story continues with...

Scatterlogic Part Two

November 11, 2001

Forward of Introductiveness

It's always a danger with these stories, that in highlighting all the crapness about a company, and having a good chuckle about peoples' ineptitude, the whole thing becomes a bit one-sided and I neglect to mention any of the good things. But then, that wouldn't make for fun reading. It's as simple as that. Just this once however, John would like to point out that he had a great time at Scatterlogic, and even the crap aspects were far outweighed by all the good stuff. If anyone reading this believes themselves to be from "Scatterlogic" (wherever that may be), just remember this is all in good humour. John wishes you all the best of luck...

 

Calvin the Stubborn Manager

The company's development manager, Calvin, was a stubborn beast at the best of times. He generally refused to cave in over any issue, except maybe after a painful two-hour dispute full of circular logic and the exhaustion of every possible avenue of argument. His stated theory behind this strange behaviour was that if the victim was still prepared to argue their point after two hours of torture, then he or she must feel strongly about their convictions, therefore is probably right.

How unproductively the afternoons were whiled away...

Calvin's favourite tactic was to use analogies to augment his argumentative stance, deliberately throwing his opponent off-track. This was a guaranteed argument-winner - because after all, who cares about the welfare of the company or the project - Calvin mostly wanted to save his ego by proving himself "right", by fair means or foul.

For example:

Programmer: "We cannot do this in 2 weeks, it needs at least four times as long."

Calvin: "Let's compare it with an Eskimo tribe taking fishing trips in a skidoo, darting around ice floes..."

Programmer: "What??"

Calvin: "The ice floes drift, this way and that, throwing the skidoo many miles off course. But it always gets there, and they catch their fish. The Eskimos are determined. The Eskimos want their fish. Are you saying the Eskimos should have simply given up and let their families go hungry?"

Programmer: "Well, I mean no, but..."

Calvin: "I thought so. 2 weeks it is then. You see? I rule supreme."

Two weeks later, the angry Calvin would demand to know why the project wasn't finished, as he had "promised the sales team".

Calvin also had an insistence on employing mostly cheap staff. Much of the time, this habit was probably more due to cost-cutting directives from the leadership team, who had their expense accounts to feed. However, Calvin certainly immersed himself a little too enthusiastically in the task of fulfilling this directive to the letter. Unfortunately the "cheap staff" directive clashed annoyingly with the other directive from on high, which was: "We want to be a kick-arse world-class software company." Except they wanted to do it with shareware-grade staff.

 

The Daily Builds

All the VB programmers were expected to check in working, compilable code at the end of each day. A culture of sharp and repetitive panic was successfully achieved by their project manager, whereby programmers would scramble to hack their code into working shape - regardless of what it takes - by the end of the day, as if the project was due to be released tomorrow. This took place even when the deadline was not due for another six months.

Of course, this practice lead to the software being hugely buggy, and not being released for another six months after the deadline. Even when the software was released, the project was not considered safe for release. However, the directors and sales team were crying out for a released product, so out the door it went.

Although the product was awarded its valuable "Code Complete" stamp on the day of its release, a large proportion of functionality had not yet been written, so work continued apace with renewed vigour, determination and panic - the intention being to release regular "service packs" that would make up the missing functionality.

Sometimes two or more builds were executed in a single day. A regular "hall of shame" email went round, highlighting the programmers who had checked in non-working code. It didn't matter if they were halfway through writing or fixing a hugely complex piece of code, into the melting pot their module went with everything else, so that the product was always "up-to-date with the latest fixes". Poor bastards.

There was no long-term thinking. The entire year-long project was managed with a hopelessly incompetent, daily cycle of panic and re-panic.

Thankfully for John, his own part of the project was insulated from all this, as he was left alone to manage it himself. Therefore he was able to follow his own build cycle - build when the code is ready - instead of a forced rigeur of artificial releases. "Let's pretend we're at code-complete stage! No matter that most of the code is half-complete and badly hacked due to this daily cycle. Let's just build what we've got and then watch the sales team's faces as the product fails to even start up, crashing horribly and taking Windows down with it!"

 

The Muppets

On one particularly busy day, one of the programmers hit upon the idea of comparing each member of the development team with a particular Muppet. This idea went down very well, and soon the programmers were hard at work, sourcing Muppet pictures, drawing up comparison matrices, and generally immersing themselves in this ad-hoc task. In fact, the unofficial project was interrupted only by the frequent outbursts of Nerf-gun battles sweeping across the development room floor.

Eventually, the task was completed. Great guffaws went up as programmers saw their respective names next to pictures of The Great Gonzo, Fozzy Bear and Sweetums. John, meanwhile, had been compared with Sam the American Eagle - something that both he and the other programmers saw as most appropriate, though probably for different reasons!

 

Great Comedy Duo

John's next project was larger in scope than his previous effort, so he was very pleased that he would be allocated some programmers to help him out. However, he had not reckoned with being allocated the two cheapest, daftest programmers on the planet. Quite (almost) literally, he got Laurel and Hardy.

Halfway through the project, Hardy was about to take a two-week holiday, so he needed to explain everything he'd been doing to Laurel. He was all set to spend his last afternoon (before his holiday) starting a new code module, when John stopped him and suggested that perhaps he should instead bring Laurel up to speed with what he'd been doing. Hardy nodded his agreement, and John went out to get some lunch.

When he returned, the comedy duo were sitting together, huddled around a PC, studying its screen with furrowed brows. This was great, except that instead of Hardy explaining things to Laurel, Laurel was explaining everything to Hardy! So John had to interrupt their enthusiastic preamble, and explain to them (again), very slowly, that Hardy... is the one going on holiday... therefore Hardy... needs to explain his work to Laurel...

During these sort of exchanges, Hardy and Laurel would glare at John with expressions of resigned accusation - like "you're being so *naasty* to me but I don't know why..."

John explained regularly to Calvin that despite his best intentions, and despite the fact that they were "really nice guys", Laurel and Hardy were just not suited to be programmers, and could he purleeease get some replacements. Calvin, however, would hear nothing of it. He explained to John (by way of a spurious analogy) that he was being "negative", and that a good team leader should make the most of the materials he has available and at the end of the day still win through.

Well, (spurious analogy time), imagine a goldmine that has been tunnelled many miles beneath the surface of the Earth's crust. You have been tasked with taking it over and digging further, "pushing the envelope" to new frontiers of achievement and endurance that mankind has never before reached. However, due to cost-cutting, the only tools you have are a Minnie Mouse oven glove and a wooden spatula for digging through the rock, and bouncy rubber struts to use as tunnel supports.

At the risk of piling analogy upon analogy, your employer assures you that "that guy managed to dig a really long tunnel in the Shawshank Redemption, so I'm sure you'll apply your ingenuity and determination, and do a really awesome, class-A job. Make this mining company proud!"

 

>> Next Chapter: Scatterlogic/Hype Machine Part Three

<< Back to True Stories

All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright © 1998-2008 Matt Stephens. ALL RIGHTS RESERVED.