Believe it or not, that was a piece of "advice" that I discovered while trying to fix a problem with Google Chrome. The question was about a browser, but the answer was about an operating system. It was clearly not helpful, at least in dealing with my immediate problem.
On the other hand, pseudo-advice like that is very useful if you want to understand the state of the technology industry in 2010. It's the subject of this autobiographical psychodrama that I might entitle, Personal Computers Are Not Appliances. If you decide to read on, let me warn you: it's a terrifying tale of reasonable people at the mercy of unreasonable levels of complexity and unreliability. During this exposition, you'll encounter interesting characters like the Apple iPad, Google's business plan (of sorts), Marc Benioff, and our evil cat Kelly.
When Chrome Lost Its Shine
Yesterday morning was crunch time at stately Grant Manor. The quarter was coming to a swift end, which meant all kinds of deadlines for research documents, expense reports, client projects, and a variety of other tasks. Regular activities, such as phone calls with technology companies about their latest product and service offerings, still happen during these hyper-busy periods, when time becomes so compressed that it fails to serve its basic purpose of, in the words of Richard Feynman, preventing everything from happening all at once.
Realistically, comments will have an impact on the final document if you post them by the end of the week. After that, I'll be writing the actual document.
Also worth mention: in drafting the outline, I realized that some of our earlier work on B2B evaluation, selection, and adoption is applicable here. Expect to see a cameo appearance from some of that interesting research in this document.
In the last couple of years, an increasing number of technology companies have discovered, or rediscovered, or redefined their own portfolio. Here are a few examples of where you can see this new appreciation of portfolios:
Using the portfolio to define alignment. Recently, I wrote a profile of Sterling Commerce's efforts to deal with the inevitable misalignments that occur in any company with lots of products, particularly after making acquisitions. Their decision to use the portfolio as the instrument of realignment is by no means unique, but it wasn't as common several years ago as it is now. (And it's still not as common as it should be.) Vendors like Sterling have to take two steps for realignment to succeed: (1) define the portfolio clearly, in a way that suggests measures of misalignment; (2) enforce this standard on people who would otherwise continue moving in the same direction unless acted upon by an outside force. Not everyone has succeeded at both, or even understood that both were necessary.
As someone who has worked in development teams, I take it for granted that not everyone on the team has the same needs and interests. A twenty-something Java developer, fresh out of college, is interested in questions like, "Which emerging framework might be worth learning?" The architect on the team may be interested in the same frameworks, but for entirely different reasons. Unlike the rank-and-file developer, the architect has decision-making power over which framework to adopt. The architect bears responsibility for the long-term consequences of this decision, while the rank-and-file developer is primarily concerned about delivering components written for whatever framework the team selects. Meanwhile, the development manager has to oversee the work of both the developer and architect, ensuring that, collectively, the developers and architects and testers and everyone else deliver their work product on time, at an acceptable level of quality.
Different roles, different questions -- not a hard principle to understand. When applied to developer support, it means that developer conferences, discussion forums, and other resources must tailor their content to a specific audience. Not surprisingly, the material interesting to developers might not be as interesting for architects, and vice-versa. (And if you're still not convinced that the two roles have different needs, take a look at the chart in this earlier blog post, which shows the sources of information and advice to which developers and architects turn.)