Three stories: Tilting at Windmills

Remember those jokes about studying by osmosis back in undergrad?  Put the textbook under your pillow and learn in your sleep!  That was a funny joke, at least the first time, right?  Right?

It turns out the whole world runs on the same principle behind “learning by osmosis”.  “We have this problem, let’s do something totally arbitrary and hope it goes away.”

Story One

A mid-sized organization came to me for an iPhone app. What do they want it to do? They’re unsure why they need it, just that they need one. So far, so normal–lots of people are completely unsure why they do things, particularly in a large organization. They just needed a skilled, contractor/consultant combo to figure out what they need and then build it.

…Or did they? Because what they actually did is went out and bought five Macs. Not five developers and five macs. Just the macs. In boxes. Perhaps their strategy was to attract that elusive sector of the consulting market which is highly skilled but has somehow arrived at those skills without ever purchasing a computer. Or perhaps they thought that with enough Apple products in a room, the necessary skills would just rub off on an already-overworked ASP developer. Someone needs to go back to the Discrete Math lecture on necessary vs sufficient.

In any case, my contact reported to his boss the necessary fire-and-motion, and five paperweights were added to the back of a network closet. Where they remain, still in shrinkwrap, to this day. Technically, the project is still active. I have seen an official memo to the effect that the project is on-schedule and that the talented team of five cardboard boxes in a network closet expect a release within six months, although there is “some risk” of schedule slip.

Story Two

A large, well-funded software company moves to town. They are desperately trying to hire 100 iOS developers, in a city where there are perhaps only 150 qualified individuals, total, all happily employed. To quote them directly, they “would rather die in a fire than work with a contractor” (which, by the way, is the probable outcome for most of these ventures).  The stated reasons are threefold:

1. There’s the perception that it’s easier to negotiate with an individual developer than a contractor if you’re a large company, because you have the upper hand, so you can dictate the terms, whereas a contractor is more like a peer that can make demands of you. Unfortunately, the perception is not true at all. In reality, an individual developer can interchange employers a lot more easily than a company can find a new highly-skilled hire. Whereas contractors, in contrast, are usually more dependent on a long-term relationship, referrals, and reputation, and have deliberately designed themselves to be interchangeable. But ignore all that.
2. The company wants to “own the talent in-house”, because employees never have side projects, moonlight, start companies, etc. Well, at least you can pretend that they don’t, whereas a contractor’s other clients are right on their portfolio page.
3. Contractors cost a fortune. Instead, you can pay some other guy $10/hour to write three versions that you throw away.

This story is actually ten stories, because there are ten companies you’ve heard of that are desperately trying to make iOS hires, whose entire hiring strategy boils down to “Let’s throw a cocktail party.” They found a lot of underage drinkers, but not many developers.

Story Three

One of the important things for a developer to do is to have a really great handle on the time and complexity of projects. I spend a lot of time thinking about how to estimate projects, both for contracting negotiations and for our internal projects.

I was caught off guard yesterday when someone asked “Why doesn’t anyone else do this?” You would think data-driven software project estimation would be a standard skill in an industry rampant with overbudget and under-delivered projects.

But in reality, it’s a liability to know when the software will actually ship. If you’re in that meeting where the execs are talking about shipping in January, and you know it will actually ship in July, well, you need to speak up and be the bearer of bad news. If, instead of estimating the project using best practices, you plugged your ears and sang nursery rhymes, you can be just as surprised as everyone else when the software is late. If you’re a product manager, which strategy has the higher chance of keeping you employed? If you’re a contractor, which strategy has the highest chance of getting you the job–the lower estimate or the realistic one?

Is it really irrational?

There’s a famous quote in technology: “Nobody ever got fired for buying IBM.” The meaning is simple: if you’re optimizing for the good of the company, you might choose another vendor, but going with that vendor has a non-zero risk of getting fired. IBM might have bad technology, but they have really good salespeople and they’re a brand your boss has heard of, so even if it all goes to hell, you’ll be fine.

When you view these stories through the lens of “build software”, they all look crazy and irrational. But when you are looking through the lens of the most impressive thing you can report at a board meeting, it suddenly all makes a horrible kind of sense.

Story 1: The Macs look a lot shinier in the powerpoint slide than some pesky contractor who can actually build the product.

Story 2: “We hired 70 people below market” sounds very impressive, if you omit the part about them being totally unqualified. Certainly more impressive than “We hired this one expensive contractor.”

Story 3: “We’re working hard to ship in January” sounds a lot better than “The data says that we can at best ship July 1st.”

Makes sense now, doesn’t it? It never really was about the software. It was about good old CYA.

The only conceivable way in which this situation becomes frustrating is in the rare event that you actually care about, and are interested in, the actual writing of the software. Silly.

Generally speaking, with a few exceptions, there are two classes of sponsors for software projects:

• Individuals and tiny companies that care very deeply about delivering a good product, but are entirely unable to afford one.  Unusually prevalent in the iOS market, I’ve blogged about this at some length.
• Companies that are big enough to actually afford a good product, but are far too large to be capable of producing one, in-house or otherwise.