In her previous post, the Cranky Product Manager unloaded on Code Boys & Grils who don't fix their damn bugs.  She dropped the eff bomb and everything. Indeed!

This post is the flip side. The developer's point of view when faced with a nasty bug.  And it's an extremely well-written piece by a Code Boy who is  a reader of this humble and cantakerous blog.  

This post is required reading for product managers. And the Code Boys/Girls will probably like it too.

(Oh yeah, go visit Quantum Whisper.  The Cranky Kid loves them so much s/he stopped mid-tantrum and calmly whispered, "Mother, I can't be expected to do agile product management without 1) candy, 2) my teddy bear, and 2) Quantum Whisper. I can't and I won't.")

-------------------

The Five Stages of Debugging

by A. Working Coder

Being confronted with a serious and difficult-to-diagnose bug can be one of the most traumatic and stressful experiences of a professional programmer's career. Those who have been through such an ordeal rate the stress as on a par with that accompanying serious injury, divorce, or the death of a family member.

Researchers who have studied the psychology of computer programming have lately constructed a framework to understand the stages through which the programmer's mind progresses as she/he works through the difficult process of resolving a bug. These stages are similar in concept to the well-known Kübler-Ross Stages of Grief, and for similar reasons. Like death and its attendant grief, fixing a bug is a process initiated by an event, at first unbelievable, which causes great anguish in the affected mind. However, this event must eventually be grappled with, endured, and brought to a satisfactory conclusion. Understanding the stages of bug fixing will make us better prepared to survive, persevere, and eventually bring closure ... to our bug queues.

STAGE 1: RESISTANCE

How you're feeling: Skeptical. Offended. Petulant.

1. Ignore it.

Maybe it'll go away.

2. Mark it as "Works for Me".

Maybe it was user error, or a local configuration problem. Yes, I'm sure that's what it was. It'll just go away.

3. Call it a Glitch.

I think it was just a weird one-off that nobody will ever see again. There's no point in figuring out what went wrong. The {database/network/browser/something} hiccuped and that's all this was. It won't come back, I'm sure.

4. Hide.

I'm taking a couple of days' sick leave. Maybe they'll assign the bug to somebody else.

5. Mark it as "Working per Spec".

Hey, look, I just implemented what was spec'd. If they want to change the behavior, UI will have to update the spec. Maybe they'll decide they can live with it as-is.

6. Demand More Information.

I can't do a thing with this bug until and unless I see the error logs for this particular exception scenario.

7. Assign it to another team member.

I was getting badly-formatted data from that other module, that's the problem. Give it to the guy who maintains that module. I could check for that one weird corner case in my module, but the proper fix is for that other guy to make his code correct. He's offshore anyway, so I'll never have to face him.

STAGE 2: ACCEPTANCE

How you're feeling: Resigned. Defeated. Annoyed.

1. Accept it.

All right, all right, all right! It's my bug. I'll fix it.

2. Put it on the bottom of your queue.

Maybe I can find another job before I'll have to fix this bug.

3. Bargain with your manager.

OK, look: I could fix it the right way, and that will take a month. On the other hand, I could apply a band-aid to the problem, which won't really solve it, but it'll make it go away as far as the end-user is concerned. And that will take a couple of days.

4. Mark the bug with an outrageously padded estimate.

God, I hope that's enough time.

STAGE 3: ENGAGEMENT AND DEPRESSION

How you're feeling: Giddy. Light-headed. Nauseous.

1. Initial Research.

I can do this. I can do this! All it takes is a little organization, a little focus, a lot of caffeine, and a little time. I can do this.

2. Befuddlement.

Shit. This is unbelievable. I can't make heads or tails of this code. It's a mess. It's a mystery to me how this code could even compile, let alone work. What chance do I have to figure out how it can fail?

3. Hide Again.

Look. I'm sorry. I had to have my appendix removed. Again. Yes, now that you mention it, I did used to have two. Now I don't have any. Happy now?

4. Bitching.

Well, what did they expect, anyway? Trying to do this without so much as a decent debugger. What am I, clairvoyant? I had better debugging tools on my Commodore 64!

5. Spitballing.

What if I try ... this? Nah, that doesn't work. How about ... that? Nope. How about ... that? Shit, that makes things worse.

6. Despair.

I'll never fix this bug. I'm a lousy coder. I'm stupid. What am I doing here, in a place full of smart people? Sooner or later they're gonna catch on, and then I am finished around here.

7. Humiliation.

My manager asked me why I've taken the better part of a month to fix a bug I'd spec'd out as taking a couple of days' worth of work. I don't know how to read the logs and I broke my own build scripts. Now I'm afraid to ask for help because it'll just make me look stupider than I already do.

8. Panic!

This thing is way more complicated than I thought it would be! The parts I thought would be really hard turned out to be really easy ... and the parts I thought would be easy turned out to be a complete rewrite of about a half a dozen classes. Why did I ever tell my manager I could do this?

9. All-Nighter(s). Withdrawl from friends and family.

(incoherent mumbling, punctuated by bursts of loud profanity.)

STAGE 4. POSSIBLY FOOLISH EUPHORIA

How You're Feeling: Grateful. Relieved. Awfully Impressed with Yourself.

1. Revelation.

Oh! Now I see how to do this...

2. Write the correct code.

I am so good. I am a coding machine!

3. Test it.

Yes! It passes that test. Yes! It passed that test. Boo! It fails that test. And I have no idea why...

4. Hide the test failures.

It's a totally unrealistic corner case anyway. Nobody will ever see that in the field. It was really a pointless test.

5. Check it in.

I'm awesome. Is there pie in the kitchen?

6. Close the bug.

I heard there was pie in the kitchen.

STAGE 5. GRAPPLING WITH THE DEFINITION OF "DONE"

How You're Feeling: Twitchy. Nervous. Superstitious.

1. They've Reopened the bug.

Really? They found another way to break it? Shit - it's that corner case I swore would never come up.

2. Fix the fix.

Yes, I'm even checking cases where the employee age is an imaginary number, just to be sure.

3. Close the bug.

Yeah, bitch. You're closed. Once and for all. Now stay dead!

4. Vow to never take on such a task ever again.

5. Realization that you are now considered the expert on that module.

Oh no! Now I've got three new bugs on that module.

At this point, you are expected to GOTO: Stage 1.

Furthermore, as a working coder, you will DO_UNTIL: Death, retirement, or promotion into management.

The Cranky Product Manager has actually not been so cranky lately.  She's started a job at a spankin' brand new startup and for the first time in her professional life is part of a team - that for the moment, anyway - seems free of major dysfunction!  OMFG!  

She has a major crush on this company and loves (LOVES) going to work in the morning.

(oops, need to insert an ad for Quantum Whisper here, cuz they buy me grande skim lattes each month. Quantum Whisper is wicked pissa. They link customer feedback to your agile backlog and all that fun stuff.  OK, back to the post.)

But being a born-New Englander -- a cynic through-and-through, to the core of her jaded, oft-broken heart -- the Cranky Product Manager knows better.  She knows this is merely the honeymoon period.  At some point, an idiot will be hired. At some point, a customer will demand something ludicrous and a SalesDroid will get simultaneously hysterical and rabid as a result, causing the Cranky Product Manager no end of aggravation. At some point, the PR agency will start arbitrarily tossing the buzz word du jour in every sentence of every press release, even if the results are nonsensical and utterly laughable.

But in the meantime, before the other shoe drops (where did that shoe dropping phrase get started anyway?), the Cranky Product Manager is trying to enjoy her enviable situation. 

The only downside of all this has been that is has been hard to get the Crank up to write this blog. Thus the drought of blog content.

So, you should all thank SugarSync for irritating the Cranky Product Manager enough that she should post.  

Some background...SugarSync is a cloud backup service that the Cranky PM pays for. She uses it at home to keep her 3 computers backed up and in sync. Cool in concept, but not so cool in reality. A few months after subscribing, instead of just backing up her files, SugarSync decided to duplicate over 10,000 files - eating up all her hard disks and cloud storage. The Cranky PM then spent lots of time using 3rd party tools to remove the duplicates. The end result was a lot of lost time and at least a few lost files.  

Irritating, to be sure. But the Cranky Product Manager is nothing if not forgiving of buggy newish products. It's what SHE DOES, after all.  So, reassured by the SugarSync Support that this was a one-off situation related to their latest upgrade, the Cranky Product Manager carried on and continued to use their service.

And then a month later it happened again.  Argh! This time the Cranky Product Manager searched the SugarSync Forums for answers and found multiple threads related to this duplicate file issue.  The most enlightening was this: http://sugarsync.hivelive.com/posts/c6fb6fb9db 

This thread reminds the Cranky Product Manager about everything that is frustrating about dealing with a certain type of Code Boy:

1. Despite overwhelming evidence in its own forums that MANY customers experience this mass-duplication of files, the SugarSync CodeBoy(s?) (username "admin") insists that this problem is a "corner case" and never really happens.  

(We can tell that it is an actual code-slinging CodeBoy in the forum, because no self-respecting Customer Support Engineer would ever take this kind of attitude with a customer).

2. The SugarSync CodeBoy then pushes the burden of the bug onto the customer -- insisting that they open support tickets, collect and mail in logs, etc... 

3. The customer doesn't send the logs in because: 

(A) They are busy manually cleaning up the duplicate file mess and don't have time to also help debug SugarSync's software, and 

(B) From the tone of the previous messages it is OBVIOUS to the customer that SugarSync does not recognize this as a genuine problem, and realizes it will be an uphill battle to convince SugarSync otherwise.

4. The SugarSync CodeBoy declares victory:  "The customer won't cooperate with me in reproducing this bug!  I can't do anything!  So, this bug must not really exist! Plus, I AM RIGHT! HAH!"

........................

Excuse the Cranky Product Manager while she strangles a voodoo doll that she created of this CodeBoy....

...OK, feeling better now.

Gotta say, it's kinda rare to see this type of exchange played out in a public forum like this. Usually the Support people rightly prevent this type of unempathetic, obnoxious Code Boy from interacting with customers and others outside the company.

But within the company, who in Product Management has not encountered almost the exact same crap from a CodeBoy/Girl, at least once a release cycle?  It is ABSOLUTELY MADDENING!   

To have someone deny that a problem exists when MULTIPLE people have encountered it?  To be told that the problem you are clearly experiencing  is a "corner case" that doesn't ever really happen?  To be told its somehow your fault - some kind of user error situation?  To have the Code Boys & Girls demand that YOU do THEIR effing jobs by spending ungodly amounts of time reproducing their damn bugs and verifying their alleged "fixes"?!?  

AS IF product managers don't have ENOUGH to do near release-end (market launch, get pricing proposed and approved, write collateral, and sales training, not to mention being neck-deep in planning the next release....the list goes on and on.), but now they have to be QA engineers as well?  

All because some frigtard CodeBoy/Girl has no effing pride in his/her work??!!  How can s/he think it's okay to release what is obviously a steaming pile to customers?

WTF!!!!!!

---

BUT THEN, serendipitously, the Cranky Product Manager received a Truly Awesome article from a Code Boy who reads this blog.  It's about the process an Engineer goes through when faced with a thorny bug.  

And now the Cranky Product Manager understands just a little bit better.  She still wants to keep her voodoo doll collection of CodeBoys close at hand, but at least she'll feel a bit more empathetic when sticking it with pins.

Read the guest post from Code Boy Extraordinaire in the next article (coming in a few minutes). It's required reading for any product manager who has ever had a bug s/he reported marked as "not reproducible."

One benefit from posting nearly 200 articles over the years is that republishing an old post gives the Cranky Product Manager the opportunity to laze about in her PJs and eat bon bons while watching the latest episode of Hoarders.  

Here's an oldie (but hopefully a goodie), from November 2006.  (Interesting to see how the writing style has changed over time.  The crankiness, however, has not changed one bit.)

---------------------

"The most challenging thing about product management is that you have all the responsibility but none of the authority," the job candidate said. Quite satisfied with his answer to the Cranky Product Manager's stock interview question, the candidate flashed her a knowing, gleaming white smile. That was the signal. The Cranky Product Manager was supposed to epileptically shake her head in agreement and, at last, connect with the candidate.

No such luck. Instead, she rolled her eyes... Not the best manners for an interviewer, but seeing as the Cranky Product Manager is not exactly a, well, refined individual, she had no control over her clichéd response to his clichéd answer. The Cranky Product Manager already heard two other candidates spin the same old tired yarn that morning. In fact, she read a version of that I'm-a-powerless-product-manager-woe-is-me tale on at least one other blog that week.

But worse than trite, overused and unoriginal, this sentiment -- universally shared by the world's lamest and whiniest product managers, and even by some of the good ones -- is way too self-congratulatory and is just plain wrong.

Yes, as a product manager, you are indeed responsible.  Your job is to corral and coordinate the hoards of Code Boys/Grrls, QA Drones, Marketing "Geniuses", SalesDroids, Professional Services Slaves, support engineers, writers, finance weenies, and more -- the entire cast of characters needed to successfully bring kick-ass products to market.

And, yes, as a product manager, it is true that you rarely have authority. No one (except maybe a few junior product managers) reports to you. You can't fire people for not taking your orders.

But here's the thing... SO WHAT!?  So these people don't report to you. So they don't have to respect your au-thor-i-tah.  Big frakin' DEAL! If they DID report to you, do you honestly think your job would be any easier?  Do you think they'd magically start listening to you and doing what you say?

Last time the Cranky Product Manager checked, high tech product folk, no matter what their job functions, were not minimum wage workers. As intellect workers, high tech-ians don't do anything  just because their bosses command it.

Nope. Those damn independent thinkers need to be persuaded. They need to buy into the plan and then they act. Sure, sure, those folks might occasionally placate the powers-that-be by half-heartedly lying there, closing their eyes, and thinking of England. But that kind of soulless attempt to merely get the boss off, uh, your back... well, it's usually worse than no attempt at all.

So, in this respect, those other "real" managers -- and by "real" I mean managers who officially manage people -- have just as tough a job as product managers. Probably tougher. People managers must ALSO corral and coordinate their people, and get them to do things that they wouldn't normally consider if left to their own devices. Like product managers, they legitimately do so ONLY by persuading and inspiring. NOT by fear nor the unspoken threat of bad performance reviews or firings. NOT by flexing their so-called "authority."

In fact, as someone experienced in both people and product management, let the Cranky Product Manager assure you that the only effective difference between a manager with "authority" and a manager without is that with authority comes a lot of tedious crap: paperwork galore, performance reviews ad nauseam, mind-numbing sexual harassment seminars, and -- most dishearteningly -- the occasional hell of laying off a subordinate who does a great job .

So, whiney product managers of the world, STOP bitching about "all the responsibility with none of the authority" right now. Get out of your minimum-wage-oriented headset and recognize that official authority is irrelevant to anyone in high tech companies. Instead consider, even if briefly, that your difficulty in getting others to follow your lead might be because your arguments are not compelling.

Or maybe, just maybe, they don't listen because they know you think of them as minions who are motivated by fear.

In other words, maybe you're a jerk.

Every time the Cranky Product Manager reads about a new B2B startup or product, she gets a sense of déjà vu.

Alas, it's not a glitch in the Matrix. It's because pretty much every single product pitch sounds exactly the same.  Watered down, generic, and 100% free of taste. 

A grinder is at work at almost every B2B software company.  A soul-crushing process that pulverizes the unique, complex, and interesting, into gruel-like messaging that the industry's lowest common denominator (and by LCD, the Cranky PM means the PR people) find acceptable and almost understandable. (see footnote 2)

Observe as the Unique Selling Proposition of DysfunctoCrank is ground into pasty mush.  (Anyone remember that game "Telephone"???)

What Development Says to Product Management: 

DysfunctoCrank's architecture uses an MPP-architecture, patent-pending modified vulcan compression techniques, Eventual Iron(TM) technology, predictive klingon data cloning,  dynamic resource kirk-ification, blah, blah, and blah.  We tested DysfunctoCrank on clusters to 64 CPUs, and it did pretty well.  We haven't tested on anything bigger.  

Remember, DysfunctoCrank uses a proprietary clustering. We're going to have to rearchitect the entire thing from the ground up if you want to support cloud deployments, and that will take the entire Engineering team at least a year or two.

What Product Management Says to Product Marketing -  For 80% of the use cases, DysfunctoCrank is about 35% faster than anything else out there and can handle double the workload of anything else.  It can scale out and scale up near-linearly, across any number of CPUs or machines, and has best-in-class features for high availability.

DysfunctoCrank can currently be deployed on-premise, but in our next release we are aiming for cloud deployments (although we still have significant technical challenges to overcome).

What Product Marketing Says to Corporate Marketing -  DysfunctoCrank delivers cloud-based reliability, performance, and scalability that no other Crank system today can match. It is the industry's most efficient, cost-effective way to achieve your business goals.

• All the benefits of the Cloud: Pay only for what you need - start small, add cloud capacity only as needed. 
• Infinite linearly scalable, supercharged predictable performance, and no wasted capacity
• Self-healing, managed reliability

What Corporate Marketing Says to the Press and to the Analysts - DysfunctoCloud is a cloud-based solution platform designed to increase your revenue, lower your TCO, and synergize with your efforts to engage users in a virtualized, Social Media Web 2.0, cloud-based world.  Plus it's in the cloud. DysfunctoCloud is CLOUD-TASTIC!!!!

What the Press Says to the World - DysfunctoCloud is just like the cloud-based offerings from vendor X, vendor Y, and vendor Z.  

What the Analysts Say to the World- In our TragicQuadrangle, we're moving DysfunctoCloud a smidge to the right on the "vision" axis, because their cloud stuff sounds kinda seksi. But we're moving them down on the "ability to execute" axis until they buy more of our consluting (see footnote 2) services.

Footnote 1:  Allow the Cranky Product Manager to continue digging at MBA programs: Business school is a similar grinder. At top B-schools, the newest crop of MBA students arrive on campus as a highly diverse group, from all professions and walks of life. Then, just two years later, 80% of the students depart as one of only two varieties: banker or management consultant. 

Footnote 2: Not a typo.

As the Esteemed Crankerati already know, the Cranky Product Manager has been creeping around the software product management universe for quite some time.  Long enough that perhaps she should replace her blog's masthead photo with a less youthful and more saggy derriere.

In that extended time, the Cranky Product Manager has encountered LOTS of product managers.  Hundreds. And thus she's heard about every lame product management excuse that ever existed.

So she's here to ask -- no, BEG -- PLEASE, STOP IT!  Please stop making EXCUSES for not doing your freakin' job.

If you can't do the Product Management job, if you don't have what it takes, if you don't have the passion and the drive, if you don't have the scrappiness to figure out how to Get Shit Done (TM), well, PLEASE leave the profession. The Cranky Product Manager begs you. 

In this economy, there are plenty of GOOD, resourceful, and influential product managers who will gladly step up and take your place. The world will be better for it.  No doubt you will be happier too.

(Note that the Cranky Product Manager knows that you, as a wicked awesome and elite reader of this blog, would NEVER be so lame. But if you could please inform all the other PMs out there, she would be grateful).

So, let's list some of the most common Product Management Complaints, and the Cranky Product Manager will explain why each is a freakin' cop-out. 

And SURE,some of these cop-outs have some validity. Some organizations are truly screwed up (trust the Cranky Product Manager, she KNOWS), and some people are real dysfunctionals.  But just as you should NEVER call your former boss an idiot in a job interview because it makes YOU look bad -- not your former boss -- don't say these things either.  Especially in the Cranky Product Manager's presence, and you never know, she might be your boss or your co-worker.  So STFU.  And Suck it Up, Buttercup.

EXCUSE #1: "The developers just do whatever they want because Product Management has no authority over Development."

Barf. And So WHAT.  Probably only 1% of product managers in the world have ever had official authority over Development.  Yet, somehow, every single day, product managers the world over manage to convince developers to take their direction.  It's called leadership. You do it by respecting people, gaining their respect back, and convincing them that your vision of the future is a compelling one.

And sorry to tell you, even if you had the power to fire every last developer tomorrow, well they still wouldn't do what you wanted unless they bought into your vision. People with brains are like that. (OK, to keep their jobs, maybe they'd do 10% of what you want.  But that's it.  They'd claim the rest was "technically impossible.")

If you want to whine that "all the responsibility and no authority" blahblah yet AGAIN, instead why not put a neon sign above your head that proclaims "I am a bottom 20% product manager, with no ability to lead or influence" instead?  It would be less annoying to the rest of us.

NO EXCUSES!

SHAMELESS PLUG! Buy a "No Excuses Product Management" mug or t-shirt!

(This post is getting way too long, so it's been broken into 4 parts.  Tune in NEXT WEEK for Lame Ass Excuses #2 ("I didn't get training").  Plus at least two more.

The following cartoon has been shamelessly republished from Shreyas Doshi’s excellent “How to Get that Next PM Job” presentation to the Silicon Valley Product Management Association.  Many years ago, during her first month at DysfunctoSoft, the Cranky Product Manager had this EXACT argument with the Engineering Manager for DysfunctoCrank:

by Shreyas Doshi

It was years ago, but to this day the Cranky PM does not understand how that a-hole could take so LITTLE PRIDE  in his work that he would insist on shipping a product with the name misspelled.

At the time, the Cranky PM was shocked. But after years in the product management game, nothing surprises her anymore.

Rest assured, the Cranky PM won this battle.  The product was NOT renamed DysfucktoCrunk.

A little link love for Shreyas Doshi, for making the Cranky Product Manager chuckle just a little bit, through the tears of frustration:

• Shreyas Doshi on Twitter:  http://www.twitter.com/shreyas
• Shreyas Doshi’s Blog:  http://shreyasdoshi.typepad.com/

Today we have a super-duper-uber-fantastic guest post from the Cranky Engineer, aka DGentry of codingrelic.geekhold.com. Check out his blog.  It’s WICKED AWESOME.

Also, you might recall that DGenery was the BIG WINNER of the Cranky Product Manager’s caption contest for the “7 Types of Engineers.” He won a fancy pants coffee mug.  AND HE LOVES IT.  Maybe YOU should buy a coffee mug too….

—————————-

From: Cranky Engineer #4
To: Product Manager #4
Date: Apr 1, 2009
Subject: Twitter reliability enhancement functional spec

Got your PRD about the 3G connectivity issues at the SXSW conference and the resulting drop in twitter volume, thanks. We couldn’t help but notice the lack of any actual requirements in the requirements document, but the main point seemed to be to “make it mo’ betta.” As mobile tower placement is subject to considerable regulation, we presume that the PRD is not calling for a build-out of a new national 3G network, but rather to eliminate dependencies on external factors beyond our control. Thus:

• No dependency on mobile network capacity
• No impact from density of surrounding buildings or obstacles
• No necessity for the presence or absence of electricity.
• No requirement for the user to own or know how to operate a computer

I think we’ve come up with a proposal which meets these requirements. The only remaining dependency is literacy. As we do not control the educational system in this country, this dependency may also need to be eliminated in a future version of this document.

Abstract of Proposal

Twitter usage is growing robustly, but is hampered by insufficient network capacity at heavily attended tech events such as SXSW and anywhere Steve Jobs gets up on a stage. Tweet volume from such events is lower than would be expected due to the connectivity issues.

It is proposed that designated drop zones be established at major tech events, where conference attendees can send and receive tweets. To avoid any dependency on telco infrastructure, tweets will be delivered to these TweetDrops by a robust and innovative mechanism.

1. Encoding

Each 140 character tweet is printed on a 5 mm wide paper strip, which is laminated and wrapped about the leg of a single carrier pigeon. The tweet is printed using a standard UPC barcode for ease of decoding at the remote end. The lamination is not necessary in theory, but in practice the messages often need to be wiped clean before processing (these are pigeons, after all).

2. Ordered Delivery

Conversations become difficult to follow if tweets are delivered out of order, but ordering is not guaranteed by the underlying network topology in this case. Therefore an 8 bit sequence number will be prepended to the barcode, which will be used to re-order pigeons arriving at the destination.

With 8 bits for sequencing information, only 256 pigeons can be launched at a time. The next wave of pigeons cannot be launched until it is certain that all members of the previous wave have left the system. To achieve acceptable throughput the natural lifespan of the pigeons cannot be used for this purpose.
Therefore, a small explosive device is fitted before launch to place a strong upper bound on the Time To Live (TTL) for that tweet. The next wave of tweets can be launched when the TTL for the previous wave has expired.

3. Loss detection

Due to the TTL mechanism employed for robust ordering it is possible that tweets will be dropped (or, more properly, exploded) in transit. To allow for retransmission an additional 8 bit acknowledgment field will be prepended to the barcode, and used to implement a sliding window protocol. (XXX Hang on, are we reinventing TCP here? Let’s have a sit-down about this before you forward it to PM, or we’ll end up rat-holing on this topic.)

Though lost tweets are expected to be a serious burden during initial deployment of this technology, it is believed that natural selection will result in a more reliable infrastructure as the less dependable population of pigeons is removed from the breeding stock by the TTL mechanism.

4. Operational Issues

The operations cost of this infrastructure is expected to be high, due to the need for replacement of pigeons whose TTL expired in transit. It is proposed that a breeding program be established in order to replenish capacity at minimal cost. This also nicely solves the problem of providing something for the pigeons to do between major tech events.

5. Direction of Future Work

The necessity of printing each tweet on a strip of paper and scanning the paper at the destination is a serious bottleneck in the communications path. A more efficient mechanism would be to download the tweets directly into the carrier pigeon via an existing Twitter API. Unfortunately the pigeons have strongly resisted attempts to implement any such mechanism.

The TTL mechanism can reasonably be expected to elicit a negative response from both animal rights activists and civil defense authorities, and should be considered only a temporary measure to reduce the time to market. A subsequent update to the infrastructure should investigate use of electromagnets to confuse the carrier’s natural homing instinct and send them somewhere where the tweet payload they carry will be harmless.

6. Security Considerations

No thorough analysis of the security of the carrier pigeon transport has been conducted. Because each pigeon will follow a different route to the destination owing to differences in wind currents, temperature gradients, and mood, it is unlikely that an attacker would be able to capture an entire conversation.
Additionally the TTL mechanism discourages interception of the pigeons in flight.

Encryption of the tweet payload is acceptable only if the pigeons can be guaranteed not to cross from within the United States to another sovereign nation, as such would violate US export and munitions laws.

7. References

[1] D. Waitzman, “A Standard for the Transmission of IP Datagrams on Avian Carriers,” RFC 1149, 1 April 1990.

Hey!  Look!  It’s a new Cranky Product Manager mug!

It declares to the world “I AM A CRANKY PRODUCT MANAGER.“

You should get yourself one.  It’s WICKED AWESOME.

PM leaders, just think of it. Finally, the perfect present for your team of put-upon product managers–those hard-working, in-the-trenches professionals that get no love, no appreciation, no free trips to the Bahamas, and no credit.  And, given this economy, they probably get no bonuses or no pay raises this year either.

You gotta do something for them, right? Something to stave off  their burnout for at least another year…

Here’s an Elegant Solution(TM):  GIVE THEM MUGS!

Just imagine how spiffy you will all look at team meetings, each clutching your very own cranky mug.

The first 50 mugs sold get special pricing of $12.99 for the small, and $14.99 for the large.  After that, the prices will go up by $1.50 each.

You can also get a WICKED AWESOME travel mug too.  That’s what the real-life CPM is getting.

So BUY NOW.  Who says you can’t buy for next Christmas now?

Oh, and if you also want to buy some 7 Types of Engineer mugs, you’ll find them here.

Thanks, and ENJOY.

7:00 am. The Cranky Product Manager awakes.  Grabs the Blackberry Curve off the bedside table. Starts deleting spam. Opens the following email from a reader and starts laughing hysterically.

Darling Husband is startled awake and is like “what the???”

Dear Cranky Product Manager,

I have attached a picture of the real Veteran Engineer that works with me. I saw your post, the description of Mike, and bought the mug for him. He, in turn, sent me the proof that corroborates what you have posted beyond the shadow of a doubt.

Please feel free to post on the site.

All the best,
Maggie
Sr. Product Manager

And here the photo, along with Mike’s disclaimers:

• No (party) animals were endangered during the filming of this picture.
• No additional clothing was needed to be purchased by the photo subject in order to take this picture.

You will notice that Mike The Veteran Software Engineer is holding a Veteran Software Engineer mug.  The Cranky Product Manager is always a sucker for a good recursion gag.  It reminds her of her lamda calculus-filled  freshman year at a random institute of technology.

Note that you readers should all take this as a hint to BUY MUGS and give them to engineers.

Thanks Mike and Maggie, for giving the Cranky Product Manager a good chuckle!

The Cranky PM is finally getting up the energy to respond to comments on her older blog posts.  In particular, those from a certain reader who keeps inflicting violent disagreement on her.

What THE???  Who does he think he IS?  How DARE HE disagree with the Cranky Product Manager?  When is he (along with the Cranky Product Manager’s husband) going to at LAST learn that THE CRANKY PRODUCT MANAGER IS ALWAYS RIGHT. This is a fundamental LAW of the universe.  Truly.

Anyway, here is one of the violent comments that has the Cranky Product Manager’s knickers in a twist.  It is on the Divine Rules of Product Management #1: Prepping for Engineering Meetings post.

You know, the post where the Cranky Product Manager said (in a much more long-winded fashion), “If you’re going to meet with the Engineering Team and you suspect the meeting is going to be contentious because some/all will be surprised or disagree with your recommendations, then make your case with each team member individually ahead of time so that the meeting goes smoothly.”

To be perfectly clear, the Cranky Product Manager was NOT suggesting the following:

• That you BRIBE engineers using free food. Her point was that you discuss the issues with individual engineers in an INFORMAL setting. If you can do this by playing some (free) Nintendo Wii with them, then fine, do that.  (Note that the Cranky PM usually does not pay when she lunches with engineers; everyone pays for him/herself.  Of course, this only works if you mostly ask developers to agenda-free lunches. Otherwise they’ll be suspicious every time you ask them to lunch.)
• That you meet with individual engineers prior to EVERY meeting with Engineering.  It’s only mandatory before the meetings you expect will be contentious.  (Note, though, that if you frequently meet and socialize with individual developers, you can expect less and less contentious meetings over time.)

Anyway, who could have guessed anyone would disagree with the idea of meeting with engineers individually before contentious meetings?  Not the Cranky Product Manager.

During the Cranky Product Manager’s days as a hoity-toity management consultant in the McBainCG Group, this practice was called “the meetings before the meeting” and was regarded as fundamental.  The goal of Big Meetings was to get the client team officially on-board and start them moving forward with the McBainCG Group’s recommendations.  Without the “meetings before the meeting,” getting this “Let’s Go” decision was very unlikely.

Why not?

Well, first, many people — especially engineers — pride themselves on being these paragons of rational thinking (this is called self-delusion). These folks CANNOT say “let’s do it” without trying to poke holes in your arguments for a while — sometimes a LONG while, as in hours.

Second, without “meetings before the meetings,” you are leaving an awful lot — too much — to chance.  The meeting and your entire project could go to hell because someone has an objection you hadn’t anticipated and you say something stupid.  Or this common situation: an engineer is surprised by your findings and has a visceral emotional reaction against the “surprise” aspect, but instead of complaining about the surprise, s/he shoots down your findings, in public. Then, the meeting ends before you can make a proper rebuttal.  Great. Now you’ll have to work five times as hard to convert this person to your course of action.  And if this person is respected or influential, well you gotta work on other people too.

Now, as far as Saeed’s assertion that in a “rational” engineering organization, the developers will fall in line and do what PM recommends, the Cranky Product Manager says:

1. The “rational” engineering organization does not exist because it is made of people, and people are inherently irrational.
2. The so-called rational Development Team might do what you recommend even if they disagree with you. But if you want them to do a GOOD or possibly even GREAT job, if you want to keep them motivated, and if you want FUTURE projects with them to go well, then you will spend the time to convince them your recommendations are the right ones.
3. It’s much easier to be a PM if you have the loyalty and respect of the Development Team. You get that respect by giving it – by listening to others’ opinions and learning about them as people.   And don’t only talk to your developers when you want something from them.  Seriously, that makes you a user and abuser.
4. If you know the Development Team is going to fall in line with your recommendations because they are “rational” or will buy into your recommendations, the meeting won’t be contentious will it?  So, maybe this Divine Rule doesn’t apply.

Paul Young commented that these “meetings before the meetings” take a lot of time and are really only worthwhile with the lead developer/architect (not the junior developers).  Well, again, the Cranky Product Manager respectfully disagrees.  In her experience, junior developers that are not “sold” on the PM’s recommendations are often very disruptive to the actual project (even if they are quiet in the meeting) and spread all kinds of negativity.  This varies of course, but many young developers (especially those hailing from elite “Institutes of Technology”) are Hotshot types who think they are smarter than everyone else — ESPECIALLY product managers.

Solomon commented “I bet Cranky Product Manager is Asian.”  Well, maybe, but maybe not. Is this comment because the CPM’s tactics provide ways for engineers and product managers alike to avoid losing face in a public forum?  Or is it because she clearly likes sushi?  Explain?

Paco commented that the “meetings before the meetings” were important for engineers, but maybe not for other types of business professionals.  Well, the Cranky Product Manager only partially agrees.  Engineers are special because they like to think they are super-rational and analytical and love poking holes in arguments, and thus need to be given plenty of time to do this.  Further, their unique role makes it easier for them to obfuscate what they are really doing.

However, “meetings before the meetings” and getting buy-in are important for ANY meeting you think will be contentious.  NEVER surprise ANYONE – - no matter their role – at a Big Meeting where you’re seeking “Let’s Do It” approval.  Yes, this means the CEO. Find a way to give him/her a preview of what you’ll say ahead of time.

Anyway, this whole thing reminds the Cranky Product Manager of a post she wrote two years ago entitled “That All the Responsibility But No Authority” Saying.  Check it out.