Things To Believe In

This blog, for the most part, is filled with things I cannot believe in, abide by, or understand. To that end, it may seem a smidge dirgy.

However, hang on to your hat (O Lone Faithful Reader) - I do believe in some things.

• I believe in the power of usability and well-designed UIs, front-loaded in application development.
• I believe in agility and the power of confident, driven, and thoughtful people to execute it well.
• I believe in Extropian principles and the framework that they provide for optimistic rationality.
• I believe that as long as stupidity is exposed, there may yet be hope for the world.

Nevertheless, because none of these beliefs currently evidence themselves in my working life, I am forced to classify them as religion. Dang, I thought blind faith in the unprovable was supposed to feel better than this.

Me-Tings

My working life has officially become a parody of itself. Today, I attended a 7 hour meeting about...meetings.

Specifically, how to facilitate meetings. Apparently, the topic is complex enough to require a 150 page booklet, 10 handouts, one tacky training video, and a facilitator who has spent 13 years at the company...facilitating meetings about facilitating meetings.

I happen to subscribe to my paw-in-law's theory of meetings:

1. Get in.
2. Tell people stuff they didn't know.
3. Make decisions.
   
4. Get out.

Nobody gets rich or famous telling people useful stuff these days. Work? We're here to work? I thought we were here to play Patty Cake, and make popsicle stick frames for our mums, and those cool potato stamps. Oh, and finger paint! But I digress.

This is the same (pre)school of thought that our newest analyst implant, Airy Fairy, hails from. During a ridiculously circular discussion about what the purpose of a series of meetings was to be, the user suggests that we understand what IT expects to deliver as a result of attending the meetings.

"Well, the hope is that we can complete the to-be analysis in preparation for the use cases. We'd also like a feature list," Analysis Manager suggests.

"And for my part," Mrs. SME adds, "I'd like to solidify buy-in and educate all at the same time."

"So," I venture, "Our purposes are simple: Get buy-in, educate, and make sure we have close to complete information for IT deliverables."

"Weeeeeeell," Airy Fairy trills, tossing her hair, "I'm not sure I'm on the same page there... We shouldn't say the purpose of the meetings is to help with the deliverables. They're only an input to the deliverables!"

So let me get this clear. We have to have the meetings in order to produce the deliverables. In what way is this not a purpose of the meeting?

"See," she continues in her mock-thoughtful tone, "these sessions are meant to be free-thinking brainstorming, where the users are generating creative, wonderful ideas! We can figure out the requirements from there!!"

Okay, someone sit this girl down and explain how babies are made. After 10 years at the company as a business analyst, she admits that this is the first major interaction she has had with users. Clearly she believes that users and IT just hold hands, skip through wheat fields, and magically produce requirements.

"Uhhh," I stammer, "Surely we don't want to go through this whole exercise, and discover that the information did not cover what we needed to get our work done?"

After talking herself round a few more loops, she concedes that maybe something that needs to be addressed during a meeting could actually be considered a purpose. Well done, AF, you get a gold star for effort!

The Dough Boy

To an outsider, it appears that the development team is run by a pudgy but affable life form: the Dough Boy. He laughs easily and seems harmless enough. After about a week working with him, however, it becomes quite obvious that the sunny exterior harbors nothing but a spongy, air-filled mind with the surprisingly destructive power of the Sta-Puft Man.

Recently, a spirited conversation began between the UI development lead and me.

"I'm not sure. I honestly think this override grid should have in-line addition for ease of use," I ponder.

"Well, I'm not so sure myself," the UI dev lead argues. "This has already caused some significant overhead in the past. It's not an easy thing to implement, as you know."

"Yes, yes... But the fact remains that the users will be putting in loads of these at a time. Do you really want them to have to go through a modal dialog every time they enter one of these overrides in?"

Dough Boy pops up out of his chair, and we both try very hard not to notice his gormless grin appearing over the cube wall.

"Maybe we should pose the question again to the user," dev lead wonders.

A beach-ball shaped mass with embroidered cuffs bounds around the corner into our peripheral view. Without voicing anything, we both know that our conversation is only about 30 seconds from being resolved.

"I've already asked her about a million times, dude! C'mon..." My voice gets ever so slightly panicky.

"Hi!!!!!!" DB interjects. If we don't acknowledge his existence, there's a 20-80 chance he might just go away. 25 seconds and we'll be done.

"Look," dev lead smiles at me, amused at my pain, and then smiles at DB, "maybe we could just confirm?" 20 seconds.

"Hey guys!!!!!!! What's this about?!?" The glare from his ignorance temporarily stuns us.

"Oh, hey," I mutter flatly, "we were just finishing up talking about the overrides screen, and whether or not the entry should be in-grid or modal." 15 seconds. With any luck, the use of technical terms might distract DB, since the last time he touched code was when people knew that Smalltalk wasn't what one did at boring parties.

"What are the overrides again?" Is that the sea I hear in DB's skull? We're done for. Something that would have been resolved in 30 seconds has now been diverted into the Management Roach Motel - issues go in but they never come out.

We spend about 5 minutes explaining carefully what overrides are, pretending that we hadn't explained it to him 20 times before in the last 2 months of development.

"I still don't get it. What exactly is being overridden?"

Kill me now. Please. There's a reason why he's not the Dough Man. The development team is headed up by the intellectual equivalent of a toddler.

Without a trace of remorse or shame, DB finally announces, "I'm still not clear on this. We should have a meeting to go over it some more. And also, can someone enter this into the issues database? Let's see what everyone thinks at the issues meeting tomorrow."

Lord have mercy. Despite all our pushing, the Dough Boy has rolled back to the bottom of the hill, along with our quick resolution. Once an issue gets into the issues database, it is discussed at 3 meetings per week, each with at least 10 people in it. None of them know the issue, so it will need at least 5 minutes of explanation, then 10 minutes of freakishly uninformed debate.

Multiply DB's duh-reka moments by at least 5 times in one day, 5 days a week. The number of completely pointless meetings swells to epic proportions. DB no longer has time left in the day to plan the team's work, or lick the development manager's manure-crusted boots. It's probably just as well because he's still trying to figure out where the ball from his optical mouse has gone.

Them and Us

In my more impressionable days, it seemed as though the problem was very much the classic Us (ranks) Against Them (management). These days, I'm more likely to say that it is definitely a Them And Us problem - in the most literal sense possible.

They cannot plan their way out of a paper bag;
They are blindly committed to Waterfall, talk RUP, and vilify Agile;
They are motivated more by perception and appearance than by doing good honest work;
They abhor the idea of users being part of a software team;
They believe employees should put up or shut up;
They are completely ignorant of the goings-on in the ranks;
They haven't coded or authored analysis documents for decades (or sometimes ever);
They believe that bigger is better;
They think that the users should be lucky to have them running the show;
They are willing to lie, cheat, steal, bury bodies, and be otherwise dishonest to look clean;
They talk about collaboration but force decisions down the chain;
They do not see value in efficiency or solid, high-quality work, if they can see it at all;
They cannot detect poor-quality work, or do not act to remove or correct it;
They are afraid of change and criticism;
They position themselves more with the management above them than with the product, clients, or people they are meant to care for;
They fill days with meetings which mostly produce no results;
They avoid responsibility and accountability wherever possible;
They make up project plans to reflect current schedules, so everything is always on time;
They threaten and intimidate employees who show signs of discomfort;
They are incapable of independent and reasoned thought.

We are infused with barely competent, confused programmers and analysts;
We are more intent on gaming the system and looking good than perfecting our skills;
We have in our ranks vicious liars who instigate and divide us;
We gossip, mutter, and plan against each other;
None of us are willing to stand up and be honest to management or one another;
We are filled with people who think they know everything, whether or not they do;
We don't have the power to enact truly effective changes to the team;
We claim to collaborate but form socially exclusive cliques which are obvious in the work environment;

Above all, we are so wracked with anger and frustration that we believe the only problem is with Them.

Forming a united front with the complainers has lost all appeal to me, when it seems obvious that the failings within the ranks themselves contribute in significant measure to the fractious team environment.

Patient, heal thyself. Only then can we baseline exactly how bad they are.

The Ravin'

Once upon a midday dreary, while I pondered VB theory,
Over many a search on Google Groups and more,
While I sat there, Cheeto-snacking, suddenly I heard a thwacking,
As of something slowly cracking, cracking in the project's core
"'Tis the character," I mumbled, "cracking in the project's core
Only this and much much more."

Oh so fondly I remember it was in the bright September
That all the project's members counted under one full score.
Possibly it might not matter, that the team was getting fatter,
That the overhead would shatter - shatter clean the team's rapport
Or the pure and simple mission that the software was meant for
Nameless here for evermore.

And the constant change in all direction of development intention
Clocked me - shocked me with horrific bumbling never seen before
And a lack of trust in worthy minds and means, I feared to say
Where's the project plan providing guidance at the project's core -
Or a rough idea providing guidance at the project's core -
What is it I'm working for?

In good time my soul felt stranger, fearing for the sponsors' danger,
"Wait," said I, "and linger, truly these requirements I abhor
For the truth is they are lacking, and the logic isn't tracking,
And the product may be cracking, cracking at the project's core
It may yet be saved perhaps" - here I did to them implore;
Silence then, and nothing more.

Deep into the chaos veering, still I stayed there working, fearing,
Slowly planning plans no worker should have had in store.
For the only way to do good, was to do the things one could,
Hoping that the work would stand out, work the users would call for,
This I tried out, and by chance the work the users did call for,
Simply this and not much more.

Back into my cube walls hiding, all the code I started writing,
Yet once more I heard a cracking so much louder than before.
"Maybe," said I, "maybe that is something that will disappear;
Let it be please, not so near, and this noise I shall ignore -
Let me work a moment more and the noise I shall ignore; -
'Tis the team and nothing more!"

All the work I did deliver, but then a sudden wind did shiver,
In my path stood colleagues livid woken from their year-long snore.
Not the least courageousness had they; no ideas brought forth did they;
But with spite they headed promptly, straight into the project's core -
Played upon the boss of bosses just within the project's core -
Whinged and spat, and nothing more.

Then this management force unknowing made my anger start full flowing,
When they failed to see the problems of the ignorance they bore,
"Though those wages you're commanding, you," I said, "lack understanding,
Who you should be reprimanding for the crimes that you abhor -
Tell me do you really think it's working hard you should abhor?"
Quoth the bosses, "Here's the door."

Honesty and Cannibals

There is something deeply disturbing when, during a perfectly open conversation, one's manager admits that his allegiance is not with the people that he manages, not with the product that he aims to produce, not to the clients of the software, but to his own manager.

I am thoroughly baffled by the combination of bare honesty and striving self-preservation. What is the story behind it? Has the project's atmosphere declined so far and so quickly that it has driven a sensible and clever man to abandon all hope of fine software, in favor of looking after Number One?

Or do I witness that rare breed, the Plain-Sight Machiavelli? "It's all about me, and I'm not sorry."

For someone who (perhaps pathologically) clings to honesty as a core value, I can't help but admire this character trait I have found so lacking in the team. Whether it's people who are not honest with themselves about their own capabilities, or those who fabricate stories to instigate others, I have grown tired of masquerades.

I hope to be plain as day to all comers, but I also beg them to make their own judgements based on their experiences. Recently, on the encouragement of a kind, seasoned colleague, I was just as plain to my manager about the way things seem to be going on the team.

In return, he showed reciprocal frankness which gave me hope. Until this last admission. It showed me exactly how naive I have been in my belief that honesty is everything. In one simple and direct statement, he taught me that, unfortunately, there is no guaranteed correlation between truth and trust.

Said the cannibal to his friend, "You look awfully nice today..."

Analyst Deathmatch

"Welcome to ringside seats at today's special edition of Analyst Deathmatch, where we bring you not just two contestants, but all EIGHT (yes, count 'em, EIGHT) business analysts of the project, all together in their pasty, humorless glory. It's gonna be a fine scrap, Johnny, these folks look hungry!"

"Well, Jim, hungry for BLAME!"

"That's right, and boy are they going to dish it out today! Ref's in the ring, conference call is started, let's ... get... READY to BUMBLE!"

Ding!

"Puffed Up Ego Of The Month is really going for it, Jim, he's just finished filing his teeth and bounce slouches to the middle of the ring. I think he's going to use his Synthetic Modesty moves on everyone -- they won't know what hit them, aside from a hazing swirl of 80's plaid!"

PUEM (in halting Taiwanese accent): "I'm. Just a lowly ex-developer. What do. I know. But." Stops to grin menacingly. "All my documents are. Checkedinand. They are so great that. The developers finished. Coding before I finished writing them." Grins.

"Oooh, Johnny, ouch-tastic! Puffed delivered a blinding spotlight on himself that has distracted the entire rest of the line up from the task at hand! They are now milling around, stunned and blank. The ref's gotta step in and restore order... But wait! Perky Pet Analyst is about to leap off the ropes for a direct slam!"

PPA: "Well, I've been conducting interviews with everyone, including the QA team, and they have concerns about the proliferation of document formats, and of the clarity of the use cases. They're struggling with the inconsistency and lack of detail."

"That's why we call her the Percolator, Jim, that swell use of the Elbow of Truth. She's a natural."

"Look at them circling now. They're at a standoff. Ref's going to step in to get things moving again."

Analysis Manager: "C'mon, let's have a clean fight. Let's talk about Point #11, 'Stop sending repeated and conflicting messages to the users.' Go!"

Soulless Himbo Backstabber: "Well, I brought this point up because it just seems like the users kept getting the same questions over and over again. For instance when I accidentally asked a user something that Clueless Divo had already found out two weeks ago. She wasn't very happy... But I do think it's getting better!"

"Wow, Jim, what a skilled use of the Teriyaki Slice melding into the Hypocritical Oath. Himbo's really got Divo on the skewer... Nice New Guy is cowering in the corner, under his business process modeling tool..."

"Divo seems to be down for the count. Who's gonna love ya now, baby?"

"Oh wait, P. Doff is somersaulting in to the center after looking rather lifeless!"

PD: "Actually, I found that when I was working with Divo, he was quite good at communicating all the changes he made. The process there seems to be working fine. I have no complaints."

"Nice deflection of the Slice back onto Himbo. But I don't think that's gonna help, Johnny, Puffed is coming in for another kick on Divo!"

PUEM: "Maybe. Doyouthink. There were so many questions. Because the requirements written. Weren't clear?" Grins.

Laughing Cow: "Hnrrrrh, hee hee. Yeah, I'd like to add something. Maybe we could implement the JAD sessions I brought up? Hee hee hee!"

"Sweet Mother of RUP! The dozy Cow doesn't know much, but she sure knows how to drop those fancy acronyms! That's gotta hurt..."

"I know, Johnny, this team'll be picking pieces of bleeding edge acronym out of their backsides for weeks!"

"Check it out, Jim, Next Stage Analyst is bouncing off the ropes with what looks like an IMHO Choke. He's sure got a lot of IMHO to deliver - he's a certified Project Management Professional!"

NSA: "In my experience, unless the requirements are extremely complex, I've found that JAD can be total overkill. But that's only my opinion."

"Yeah! Totally PMPin' moves from Next Stage... It'll be hard to top that!"

Ding Ding!

"Oh dear, folks, the conference call has just run out of time, just when things were getting interesting! You'll just have to tune in next Tuesday at 11 to find out who rules the roost, who puts the BS in BSA... Only on Analyst Deathmatch!"

Coding in Hollywood

News of a friend's recent engagement took the edge off the futility of corporate software development today. Instead, I offer a product of one of my long-lost fanciful moments.

Half the Users, Double the Absurdity

During a recent conversation, one of the users noted that half of her group does not intend to use the new software that our project is building.

So, the breakeven point is now 2,888.888 years of the manual process.

Double the absurdity, double the fun,
Double your mess with budgets that stun!

Beached Whales

They're big.

They're smelly.

They're either dying, dead, decomposing, or a combination of two (except, of course, dying and dead).

And there's no easy way to get rid of them.

Yes, folks, if you are at all familiar with corporate IT, you may have laughed at one. You may have cried because you were personally crushed by one. Either way, you can't escape the Beached Whale Project.

It starts out so tiny and cute. But before long, it's hoovered up more than its fair share of the natural resources. Uncomfortable bloating causes an inability to focus on normal life operations.

Having depleted the supply of resources in its immediate surroundings, it wanders, confused and aimless. It forgets why it got so big to begin with. All it takes is one bad wave, and it's on its side, unable to save itself from certain death.

A crowd begins to gather. At first, great publicity prompts a sympathetic and hopeful public outpour. Maybe something can be done!

But after the cranes topple and the backhoes falter, annoyance sets in. The public gets bored.

And after the pong starts wafting, the crowd disseminates, unwilling to be associated with the rot. Scavengers settle on the outside, picking at the odd resources peeling away. Decaying morale eats away from the inside.

"Hey, guys, I'm still alive, you know!" it whimpers.

Soon, the pong turns into a stench and the nearby denizens demand action. But the authorities are stumped. They can't can the thing - there's too bloody much of it. They can't deny its existence - people can smell it for miles. And they can't just leave it - it gives the place a bad reputation.

"Guys...? I'm still here!" it cries.

Nope. The only thing to do is to dust it off loud and proud. Pack it full of TNT and blast its blubbery goodness into parts small enough for the scavengers to scuttle off with.

"Oh dear..."

The fallout may crush the odd bystander or two, but at least it'll be over quickly. And besides, it's cheap and thoroughly entertaining. It may just work for IT projects better than it did for this poor fellow.

Math Destruction

So 10 o'clock rolls around, and after some brief preparatory scribbling, I submit to being interviewed by Perky Pet Analyst. She explains the whole process to me, lays out proof she really has solved the world peace problem before, then settles into serious mode.

"So if you could do anything to improve the way things work around here, what would you do?" she inquires.

"Fire half of us," I offer happily.

The subject of mathematics occupies my thoughts a lot recently. The illustrative simplicity of numbers surpasses any amount of words. If the project were a textbook problem, it would read as follows:

Q1: It has taken 2 years for a group of 50 people to learn and program what 4 people do in 3 hours every month. If each of those 50 people are budgeted at $100 per hour (assuming a 40 hour work week), for how much money have the project sponsors been screwed?

A1: The project sponsors have been diddled out of $20,800,000.

Q2: Assuming the same billing rate for the group of 4, how many years will it take for the project to break even?

A2: Those 4 people would have to be doing the same thing for 1,444.444 years before the project becomes economically beneficial.

Whoever said math isn't fun?