Last year, colleague Mary Gerush and I wrote overviews of the requirements tools market, noting how it was segmenting to address different problems. (Click here and here for the two studies.) Application lifecycle management (ALM) tools may be undergoing the same evolution, forcing us to accept either a much larger definition of ALM, or several specializations within ALM.
In the requirements market, new tools, or new emphases among tools, were a sure sign that some kind of change was afoot. Several years ago, visualization tools were not only absent from the list of requirements tool capabilities, they were almost completely unknown. Now, any list of requirements capabilities that omits visualization would be incomplete. Several years ago, requirements management was the emphasis of these tools. Now, much of the interesting innovation is happening in requirements collection.
He's absolutely right. Adoption is often unrelated to the potential value of technology or the intensity of a person's need for it. An entire branch of social science started because farmers wouldn't always adopt better-producing seeds and people living in areas at high risk of an epidemic wouldn't take the medicine needed to prevent infection. Many doctors don't like electronic medical records because they're used to pen and paper. This sort of resistance can arise from a variety of sources, many of which are not strictly "political" in the way we commonly use that word.
While that might be an easy principle to accept, here's a corollary that's much harder one to swallow: Nobody is immune. If you think you're somehow smarter about technology decisions than a farmer, think again.
There are blog posts that you can write without doing any prior work (he says, looking meaningfully at himself in the mirror), and then there are blog posts that require real work. This very interesting post about how the Facebook development organization operates is in the latter category. Instead of pointlessly summarizing the author's findings, compiled from sources who know Facebook from the inside, I'll add a few reactions:
If, as reported, the development team comprises about a quarter of the company's employees (and operations another quarter), that's an unusually high ratio for any tech vendor, whether or not it's in the software-as-a-service (SaaS) business. At salesforce.com, R&D comprises 15% of the company, which is high for the tech industry. Facebook's 25% R&D is staggeringly high.
Even though Facebook regularly confuses the heck out of the people with changes to security features, the company does pilot features before shipping them.
Facebook developers bear a lot of responsibility for their own code, across many dimensions of quality (design, testing, justification, etc.).
The ops team has a more gradual approach to deploying new code than it might appear.