[​​White Belt] Keep a watchful eye for stupidity—it could strike at any moment.

You may have heard of programming design patterns, where people have identified recurring patterns of programming solutions that have proven useful. This section is the opposite, a collection of recurring patterns of business practices that have often proven counterproductive, misinformed, or downright stupid.

You won’t be able to fix these yourself; problems at this scale can take years and many hands to build. I document these as a warning, in the same way that wilderness survival guides include pictures of poisonous plants.

Will any of this business buffoonery kill you? No, but it foretells rough times ahead. If you hear “The schedule is king,” your project is heading for a death march. The hockey stick sales curve is often followed by flat sales.

So, take note, and be prepared for a new job search if your company turns poisonous.

The Schedule Is King

Project managers love Gantt charts. Remember the simple one from ​Waterfall Project Management​? Imagine that with 500 lines and 100 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 eighteen months. But there’s a catch: the product really has to ship in eighteen months. After all, there’s this scientific-looking graph proving it can ship in eighteen months, right? The rallying cry is, “The schedule is king.”

Nobody can predict a complex project eighteen months out. The intricate Gantt chart is based on wild guesses and assumptions that couldn’t possibly be validated. The schedule falls apart within months.

However, management sticks 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 which bodily orifice you think they pulled the schedule out of. 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.

The Mythical Man-Month

The Mythical Man-Month [Bro95] by Fred Brooks is a famous book in the high-tech world. It seems like everyone has read it. It seems like everyone has 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 have 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 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 a person who knows what’s going on.

The Hockey Stick Sales Curve

---

Figure 13. Don’t believe the hockey stick

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 Figure 13, ​Don't believe the hockey stick​ 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 of a 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…start thinking about other jobs.

The Big Rewrite

Programmers mired in legacy code often wish they could throw it all away and start over. Once in a while, they convince the stakeholders that it’s the right thing to do.

The Big Rewrite ensues. Programmers hold lots of design meetings. New technologies are chosen. Things are really fun because the sky is the limit on the new code base.

Then things get hard: it turns out that a lot of that gnarly code in the previous product was actually needed for something. All that nasty GUI setup code was needed by an old version of Windows, and your biggest customer still runs that version of Windows. All the special cases in the workflow code is there because those special cases are intrinsic to the problem domain. Oh no…the new version is becoming legacy, and it hasn’t even shipped yet!

Making problems worse, nobody figured on all this extra work up front. When the stakeholders agreed to the Big Rewrite, they thought it would take six months. Now the team is six months in but not halfway done yet. Not-too-kind questions are being asked by management. Your work hours get longer. And in everyone’s haste to finish, quality goes down the drain. Things are really not fun anymore.

What do you do in the face of a big rewrite? First, read Tip 7, ​Improve Legacy Code​. There are techniques for dealing with legacy code that don’t involve throwing everything out and starting over.

Second, refer to Tip 4, ​Tame Complexity​, with a special emphasis on separating necessary complexity from accidental complexity. You can’t throw out the necessary complexity. But ask the team: are there ways you can model it better?

Actions

As mentioned up front, by the time you spot one of these business-level antipatterns, it’s probably too late, and a lone programmer wouldn’t be able to fix it anyway. So, I leave you with one action: when your peers begin jumping ship, ask them, “Are there any more jobs open at that company?”