Author’s Note: it’s really hard coming up with good examples for the assembly language discussion. Either I make something meaningful that compiles into pages of assembly, or I make something too trivial that compiles into nice snippets. I’ve tried three times to write about pointers and the balance still isn’t right. So today I’m flipping back to corporate life.
Executives and managers like to think they’ve got it all together. Walk with some swagger, put on the game face, don’t show weakness. Just as you learned about your parents, your management doesn’t always know as much as they say they do. I’m a manager, I’d know.
So let’s take a tour of myths you’ll probably hear in the corporate world. When you hear these, make a mental note: this guy is a bozo.
Myth: The Hockey Stick Sales Curve
This one is my favorite, because I actually heard it at General Magic and it was later immortalized in a Dilbert cartoon. The guy puts up a chart like this and begins his pitch:
“We expect the adoption rate to be slow for the first couple quarters, but then the product’s popularity reaches a critical mass and sales take off, like a hockey stick!”
Yea, right. The hockey stick does indeed happen for some companies, but a company can’t make that hockey stick happen through wishful thinking. Ultimately the market needs to drive it. The company can’t predict if or when that will even happen. Great products sometimes wither and die, mediocre products can take off. Who knows which will hockey stick and which won’t?
An honest business case may include the hockey stick as a best-case scenario, but it will also include the reality-check scenario where the product doesn’t go gangbusters all the sudden.
What do you do when faced with the hockey stick presentation? That depends. In my case, I was having a great time and the company was still flush with cash, so who cares? I kept on programming. But if your company is small, product sales are needed to pay your paycheck, and you get this pitch… I’d start considering another job.
Myth: The Schedule is King
Project managers love Gantt charts. Remember the simple one from our discussion of “waterfall” development? Imagine that with 400 lines and a hundred cross-dependencies. That’s the kind of Gantt charts project managers actually make.
Then management buys off on the intricate schedule that says the product will ship in 18 months. But there’s a catch: the product’s really got to ship in 18 months. After all, there’s this really scientific-looking graph proving it can ship in 18 months, right? The rallying cry is, “the schedule is king.”
As we discussed with waterfall, nobody can predict a complex project 18 months out. The intricate Gantt chart is based on wild-ass guesses and assumptions that couldn’t possibly be validated. The schedule falls apart within months.
However, management may stick doggedly to the schedule—after all, the schedule is king. Throw out features, throw out testing, throw out whatever it takes to ship something on the scheduled end date. Then leave it to the beleaguered Sales and Marketing teams to figure out how to put lipstick on the pig.
What do you do when faced with “the schedule is king?” I would not recommend telling management that you think the schedule is a load of crap. It won’t help. Instead, be honest to management when scheduled tasks take longer than expected (they will) or quality is slipping (it will). Don’t say “I told you so,” just stick to the facts. A good manager will take the facts back to the rest of the company and figure out where to go from there.
Furthermore, when it comes time to cut features (and it will) then don’t immediately suggest cutting the features that are hard to implement. As much as possible, think about the product as a customer and what features you’d really want. Some of them will be hard. Regardless, stick up for the features in proportion to the value they’d give the customer.
Myth: The Man-Month
“The Mythical Man-Month” by Fred Brooks is a famous book in the high-tech world. Seems like everyone’s read it. Seems like everyone’s forgotten it, too.
The premise is that management sees a schedule slipping, and since the schedule is king, they decide to add more programmers to the project. If it takes five programmers ten months to develop the product, shouldn’t it take ten programmers five months? Fred Brooks, however, asserts that adding programmers to a late project makes the project later.
The problem is that programming in a team requires a great deal of communication and coordination. Managers will lament that it’s like herding cats. It’s not that programmers are stupid or dysfunctional, it’s just the nature of creating complex systems. Pile more people in the room and now you’ve got a complex system and a complex coordination problem on your hands.
What do you do when faced with management adding a bunch of programmers to your project? Honestly, you probably won’t get much say in the matter. The very best thing you can do, however, is talk frequently with your other team members. When possible, get people chatting around a whiteboard. Or pair up with someone when writing complex code. However you can do it, keep communication channels open. This will benefit the project but also establish you as the person that knows what’s going on.
Author’s Note: I’m going to discuss outsourcing, the Grand Cru of corporate myths, as a separate section. But can you think of other myths you’d add to this section? Leave ‘em in the comments.