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

Flapsoft

After CrapScape, John was desperate to do some "real" programming, most importantly in an up-to-date (i.e. not MS-DOS) environment. He landed a Windows programming job with Flapsoft. At last, things seemed to be going the right way: he had found his heaven, a company which actually had its own Q.A. department; a place where documentation mattered. And yet, in this seemingly magical kingdom where everybody smiled a lot, trouble was brewing.

On the morning of his first day at Flapsoft, John walked into the reception area: a strangely calm place which, he was later to realise, was a haven of tranquility compared with the panicky reign of terror which held the rest of the company in a furious turmoil. In the serene reception area, all the panic which the rest of the company exuded would melt slowly into a harmonious, breathless calm.

The company receptionist, the mild-mannered Doris (who somehow knew everything which went on in the company), offered John a cup of coffee, which he accepted with gratitude. When his new boss, Zoomer, turned up, he was lead into a vast, surprisingly packed room which in some ways resembled a crowded cattle pen. John's heart sank straight away. He had suspected that the job was probably too good to be true. Still, he decided not to make too many judgements just yet. As long as the software development cycle was sensible, he was prepared to put up with some at least moderately crowded working conditions.

He was introduced to Londo, a slightly psychotic 25-year-old whose job title was "junior programmer". John noticed fairly quickly that Londo was a rather tense character, which was not surprising given his cruel job title. Perhaps "pre-pubescent nobody" would have been a more cheery title. John was a "senior programmer": thus, even though his job was essentially the same as Londo's, an unnecessary sense of rivalry immediately sprang up between them. John only became aware of this when Londo actually challenged him to a fight a week later (as in, "you and me, outside in the car park. Now. No, I'm not kidding. I want to kick your head in.") John gracefully declined (by laughing), but only discovered about a month later the real reason for Londo's bitterness: Londo had been in the same job for over a year, and felt that John's sudden arrival into a position which was technically "above" him was an insult to his programming prowess.

Oh for a quite life, John thought despairingly.


Troubled Managers

About five months into his job, John was settling into his position nicely. The project was going well; he was learning a lot about object-oriented programming - and proper software development procedures - from his team leader Zoomer; he was also busily teaching himself new technologies on the side; and he was writing functional and design specifications; he was playing golf with Zoomer. Their team (sans Londo, who sadly refused to join in) won a go-karting competition. Everything was running like clockwork.

The project was technically a year behind schedule: it had originally been allocated six months to be completed - before any requirements had even been drafted. In those early days, no consultation had been made with the developers before the project plan had been drawn up. A re-work of the project plan revealed that this was actually a two-year project at minimum, and would therefore need to be completed in stages so the essential functionality could be placed in the hands of the customers at timely intervals. Unfortunately, the typically fragile middle management clung doggedly to the original base-line, and regularly demanded to know why, after a year and a half, the project still had a substantial distance left to run.

Zoomer had regular planning meetings with Steve Sprout, his divisional manager and immediate boss. During these meetings, Sprout would very strangely try to lay the law down on Zoomer, insisting that the project be run "his way".


The Promotion

The net result was that the fragile management of Flapsoft detected "trouble" in the unlikely form of an employee whose opinions disagreed with their own. During an organisational reshuffle (the Flapsoft management was reshuffled every month or so), Sprout was moved to a different division and replaced by, errr, Skippy the Kangaroo (I am running out of made-up names, as you can probably tell); Skippy's previous division was further sub-divided and thrown to the four winds, in the hope that they would land in some sort of orderly pattern; the Managing Director was squished between the thumb and forefinger of the multi-national which owned Flapsoft - the M.D. was sent to somewhere in Europe, and a representative from the multi-national was put in charge instead; and, closer to the ground, John's team leader Zoomer was (most unfairly) taken off that project and moved to a new one. John was promoted to the strange position of "project manager/team leader/programmer" to run the project.

Great, thought John (at first): a promotion. I must have been doing something right then. Perhaps I am pleased.

John's New Job

John had three programmers working for him: Beavis, an academic whose usual response to a question was to stroke his "goatee" beard for five minutes before finally saying, "Hmmm, that's a tricky one," whilst nodding sagely; Butthead, an American visiting the U.K.; and of course John's good friend Londo, who was actually fired five minutes later due to a separate harrassment case on a female colleague.

Also working on his team was Rachel, a dynamo-like software tester who was a great help when John soon discovered that holding down three different jobs actually takes up three times the amount of time. Time management was John's first real crisis: he knew that delegation was the key, so he set to work re-organising the project plan so that the bulk of the programming was taken up by Beavis and Butthead. Unfortunately, the main stumbling block to this plan was that Butthead did not understand object-oriented programming (not his own fault, of course, but John had to wonder how Butthead had been assigned to such an inherently "oo" project in the first place); Butthead's favourite way of tackling a programming problem was to sit staring at his screen for several days. Usually John could catch this activity out in the early stages, and could then sit with him for an hour, explaining how to program.

Beavis, the quiet academic, was not much better: when John handed him a design document for a new coding module, explained what needed to be done, pointed out the position of the module on the project plan (thus imbuing a much needed sense of urgency), Beavis would nod wisely, stroke his goatee, and promise John that he understood fully what needed to be done. When John checked his progress a bit later, Beavis would inevitably have written something which was completely the opposite of what he was supposed to have written. This would not be so bad, if he could simply have surrounded Beavis' code with parentheses, and put a "NOT" at the beginning.

"Where does it say this in the specification?" John would often ask, somewhat concerned for Beavis' sanity.

Unfortunately, these problems were accentuated because John was frequently called away for what he regarded as pointless and time consuming management meetings which would go on for hours, sometimes (through the miracle of adjournment) even days. Therefore, when he returned bleary-eyed to see how his team was doing, the image which sprang to mind was of a farmyard where all the animals have been let loose: the sheepdog is chasing the geese around the pond; the pigs are trampling the vegetable patch; the goat has broken into the farmhouse and is eating the carpet, while the cows are rampaging through the sitting room scaring granny witless.

They are all enjoying themselves immensely (apart from granny), and John can only stare with open despair, amazed that he has only been gone for the morning.


The Monthly Project Review Meetings

John was, if the truth be known, quite nervous about his first project review meeting.

"Don't worry," Skippy (his divisional manager and boss) explained jovially, "I'll accompany you for this first review. Now, as you've only been a PM for a week, you can't be held accountable for the terrible state that the project is in."

"I had no idea the project was in a bad state," John interjected.

"Sadly yes," Skippy replied, not actually sounding sad. "You see, Zoomer is not really well liked by the senior management. That was why he had to be replaced. He's too opinionated, you see."

"And for that reason, the project is in a bad state?"

"Hmm, well anyway, here's how the meeting is going to progress. The senior managers will try to blame you for the terrible state of the project. But I'll be there to make sure you don't get tarred. Don't worry about it: as your boss, I'm there to take all the flack. That's what divisional managers do, you know. It's my job. I take shit from everybody."

They entered the meeting room, where at least ten stern-faced senior managers glowered at them for no apparent reason. The company accountant sat between them, red-faced and scowling like a bad-tempered chihuahua.

John and Skippy sat in front of them. John suddenly felt very small.

"And on to Zoomer's project," Felcher (the most senior manager in the room) rasped.

"Zhoo..." Skippy started, his voice giving way. He coughed, and started again: "Zoomer's project is no longer being run by Zoomer. He is to be put aside for a while. He'll be starting a new project, which I'll go over with you guys next!" (Tried to sound matey. Failed dismally.) "Anyway, back to this project. Uuhh... codename Doom. This is my young, rising star John. He's the new PM in charge of Doom.");

"Project Doom," Felcher rasped. "I know of this one. Where's Zoomer?"

"He's not on this project," Skippy explained patiently. "John here has taken over."

"I see," Felcher rasped. His voice was like the sound of sucking eggs, only drier and more sinister. "So, John, I want you to tell me why your project is almost exactly a year behind schedule. Just what the hell is going on here? Can you explain this tardiness, young man?"

"Are you aware," the red-faced accountant suddenly snapped, "that residual forecasts for the first eight modules have been over-run by over eighty percent?"

"You're on," Skippy whispered to John, ducking.

"Um," said John, somewhat taken by surprise. He considered explaining that he had only just taken over the project that morning, but remembered that Skippy had just done that, to absolutely no effect. He realised how unfair this was, and luckily that gave him the impetus to respond:

"That's hardly fair," he said sharply. "I've only just taken this project over. The first thing I'm going to do is re-work the project plan to take into account the pretty major staff reshuffle that's just taken place. Nothing that is on the current plan can be called accurate any more." The goalposts are the same, but the pitch has shifted (he didn't say that at the time, but thought of it later that day and wished he had said it).

"I see," Felcher rasped. "Skippy, can you explain the missed targets on this project plan?"

"Yes," Skippy replied, glaring sideways at John, "we've all been working overtime to bring the project back on schedule. You know - late nights, early mornings, weekends, the usual stuff. We'll be back on schedule in no time. No need to tell the clients anything."

"That's better," Felcher spat. "Now, your extremely young and attractive new PM here will need some guidance about the presentation for the next 'grease up/bend over', that is, monthly review, in, uhh... one month I believe." He chuckled, as did the other senior managers. The accountant even patted him on the back.

"I'll see to it," Skippy promised, "I'll have him banged into shape in no time." He actually winked at this.

John emerged from his first project review meeting feeling moderately confused, not least by the homo-erotic innuendos which the senior managers had been casually throwing back and forth at each other.


Beavis the Analyst

"I don't want to be a PM any more," John stated a week or two later. "You're required to lie in order to please higher management. Even then they know you are lying, but they just want to hear this crap so they can convince themselves the company is running smoothly. Mine isn't the only project like this, is it? I get the impression that all the other projects in this company are in even worse trouble, if anything, simply because their PM's are too afraid to tell the truth. The fact is, we need to re-work this project plan. Project Doom isn't really in trouble, but the management are convinced it is because you won't tell them that the deadlines have changed."

"John," Skippy replied smoothly, "we really need to re-work this project plan. Believe me, it's the only way to get this project out of trouble. Now, stick with me and I'll show you how to smooth out these dependencies. Now, let's see... first of all, we need an extra person writing design specs. Can we get Beavis to do that?"

"No, he doesn't have the experience."

"Never mind that. My experience is that employees can be 'grown' into new positions. Just like I saw potential in you to be a project manager, I believe Beavis can be grown into an analyst."

"Sure, but not straight away. He can barely string two thoughts together, and when he does they're unrelated."

"Never mind that. Trust me, I am never wrong about anything."


The Acting PM

John ended up virtually writing Beavis' first design spec for him. He did not really want to, as this must have been quite disheartening for Beavis. He could see no other option though: after a week of hapless re-writes by Beavis, John gave up trying to explain things patiently and draw nice diagrams, and just wrote the damn things.

"How is Beavis getting on with his design specs?" Skippy asked during one of their progress meetings.

"He's getting there," John replied, not wanting to drop Beavis totally in it. "It will be a long time before he can actually write a design document though."

"Splendid. I'll put down '90% complete'. At this rate, we'll have them all done in no time. How are your own modules going?"

"Well, I haven't really had time to do those, as I've been doing Beavis' work for him. Plus all the management meetings, of course. I keep saying, I don't want to be a PM any more. Not in these conditions anyway."

An "acting PM" (Mr Pink) was duly assigned, "purely as a temporary measure", so John could concentrate on the development, spec-writing and team-leading aspects of his job.

At last the job was starting to settle down. There were still many things that were far from perfect about the job, but these were things that John could happily cope with. When all's said and done, the work was actually not that interesting. The object-oriented stuff was great, but the subject matter really was a bit boring. As the project neared completion a few months later, he decided that the team could quite easily glide in from there, so gave in his month's notice. Only a couple more modules needed to be written, and these were virtual carbon copies of existing modules.

The panicky response of his acting PM was interesting: "But you're the only one who knows anything about the project! Once it's complete, we were going to put you in charge of support and maintenance." (Holy shit, thought John: it's lucky I decided to leave!)

"It's okay," he soothed to the panicky acting PM, and explained the figures to him.

"Okay, " the acting PM said, breathing deeply. "I see now. That's okay..."

So John left, feeling fairly good about the job and the company. He was saddened to hear that the company had assigned Beavis as the new team leader, and that almost immediately the project entered "panic mode", with buggy patches being modemmed hastilly to the customers; previously working VAT calculations suddenly no longer worked and were re-written many times over until the original, working version was lost, even to the company's respectable version control system; weekends were regularly being worked by poor Beavis (something John had always refused to do, after his experiences at BodgeCo); panicky on-site programming was seen as a way of convincing the clients that they were "on the case". And so the sadness continues...


The Final Word

I will leave the final word to the "real" Zoomer, who sent me an e-mail recently with these points about just what made Flapsoft such a bad company to work for:


The problem with FlapSoft was not paperwork. That in my opinion was the good thing (the Quality System).

It just is not possible to write complex software and change it without trace. Developer-issued reports during development and project issue reports for a definitive version (or a similar scheme) are definitely the way to go.

The problem was the fact that none of the managers had any management experience/training. They simply did not understand the issues regarding software development.

They were not interested in how long it would actually take to develop something.

They believed that so long as they said it had to be done on a certain day then it would automatically happen.

They never learned from their mistakes or anybody else's.

They were more interested in managing thier relationships with other managers.

They had no idea of the capabilities of individual developers.

They did not like to be told about potential problems because they were confronted with a situation where a minion had a clearer vision than them (not just me!).

They actively tried to by-pass the quality system.

They believed in crossing bridges when they came to them (FATAL!!) and not using a map to find the easiest route.

And the worst crime of all. They simply did not appreciate that the company was there to survive and make money.

I could go on but my dinner is ready.

In the next chapter, we return to BodgeCo for a fresh round of stories. These are less to do with software development and styles of management, and a whole lot more to do with the individuals that worked there and made John's life so surreal...

>>> Next Chapter: More BodgeCo
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.