rc3.org

Strong opinions, weakly held

Author: Rafe (page 25 of 989)

What happened to Microsoft?

How Microsoft Lost Its Mojo: Steve Ballmer and Corporate America’s Most Spectacular Decline

I just got around to reading Kurt Eichenwald’s account of Microsoft’s decline in Vanity Fair. Microsoft has always held a grim fascination for me — when I first started writing this blog my number one topic was inveighing against Microsoft’s monopoly. Now Microsoft is just another information technology company. The article puts Microsoft’s drift down to two causes, a stagnation of its stock price that stopped the minting of Microsoft millionaires, and a stack ranking system that creates perverse incentives inside the company. My only criticism of the article is that it refers to Microsoft to being “cool” in the past more than once. As someone who was around at the time, I can guarantee that nobody ever thought Microsoft was cool.

Steven Pearlstein on Baumol’s disease

Why cheaper computers lead to higher tuition

Steve Pearlstein explains one of the most important outcomes of an economy with rising productivity, Baumol’s disease:

No matter how innovative people were in coming up with new technology and new ways of organizing their work, Baumol and Bowen reasoned, it would still take a pianist the same 23 minutes to play a Mozart sonata, a barber 20 minutes to cut the hair of the average customer and a first-grade teacher 12 minutes to read her class “Green Eggs and Ham.” Based on this observation, the duo predicted that the cost of education and health care would inevitably outstrip the price of almost everything else.

People who don’t understand the concepts in this column should probably not talk about economic policy until they do.

Mark Chu-Carroll on the nature of computer programming

Everyone should program, or Programming is Hard? Both!

Mark Chu-Carroll explains the nature of computer programming in response to the general criticism that programming is difficult because it requires people to understand too much about how computers work. That’s not a great summary, so I’ll encourage you to just click on the link and read the article instead.

The challenge of developing a capability

China has deployed its own aircraft carrier. The vessel is a rehabilitated Ukrainian carrier that China purchased in 1998. Unfortunately, China does not have pilots who have practiced landing a plane on an aircraft carrier, nor do they have any planes that are capable of landing on an aircraft carrier.

What’s the point? That it’s a lot more difficult to develop a capability than it is to build something. The obvious recent example from technology is the launch of Apple’s Maps application. Apple developed an iOS app that has all of the features one would expect from a cutting edge mapping application but they lack the capability to keep their own set of world maps accurate and up to date. For more on this, check out David Talbot’s article on the challenges involved in building a legitimate mapping application. As it turns out, most of the work is in building that capability.

The United States has been working on aircraft carriers for over 100 years. Not only can we build aircraft carriers, but we can also build the right planes, train the pilots, and train the rest of the crew of the aircraft carriers, many of whom also have very specialized skills. The US Navy also has the logistical capability to send an aircraft carrier most anywhere in the world along with the attendant fleet of ships to support and protect it. (For more, see the Wikipedia article on carrier strike groups.) China may have an aircraft carrier, but how long will it be before they have the equipment and expertise to conduct a pitching deck exercise?

From a software development perspective, it’s worth thinking about capabilities when you’re talking about projects. As I mentioned the other day, I’m currently working on analytics. It’s easy enough to set up Google Analytics on your Web site, but developing the capability to understand the reports and incorporate the analysis into your product plans is much more difficult.

That’s only the tip of the iceberg. There are other, specialized third party analytics tools, and from there, custom analytics software and data analysis. Beyond that, there’s the statistical math required to draw accurate and useful conclusions from the data you’re gathering, and spreading an understanding of how the math applies throughout the organization. There’s also the task of changing people’s approach so that they rely on data rather than anecdotal evidence when making business decisions.

Often it’s the case that the larger (or older) an organization is, the tougher it is to add a capability in the first place. It’s harder to teach 100 developers to use Test Driven Development and rely on continuous integration rather than traditional QA testing than it is to teach 5. It’s also harder for larger, older, or more conservative organizations to rely on a new capability that has been developed. It often happens that organizations put a lot of work into developing a new capability but they never really get comfortable enough to let it replace an old one.

If nothing else, when you’re discussing projects, it’s worthwhile to ask yourself whether the project leverages an existing capability or requires developing a new one, and planning accordingly. If a new capability is required, both the effort and the risk of failure rise significantly. I’d be willing to bet that Chinese aircraft carrier is never put into active deployment.

Anil Dash on the Blue Collar Coder

The Blue Collar Coder

Anil Dash writes about a career path for people who are coders but not necessarily computer scientists. We already see this to some degrees in areas like ops, data center work, and desktop support. I certainly think there is plenty of room for this idea in software development as well.

Ted Leung’s recap of Strange Loop 2012

Strange Loop 2012

This is a fantastic conference overview, and it happens to be an overview of what many people described as the most fantastic software development conference of the year. I’m really going to try to attend Strange Loop in 2012.

Mark Lilla reviews the conservative mental state

The Great Disconnect

In what was probably the best piece of political writing I’ve read this year, Mark Lilla discusses the huge gap between how Obama-hating conservatives and sane people perceive the Obama presidency. This describes an experience many of us have had:

Whenever conservatives talk to me about Barack Obama, I always feel quite certain that they mean something else. But what exactly? The anger, the suspicion, the freestyle fantasizing have no perceptible object in the space-time continuum that centrist Democrats like me inhabit. What are we missing?

He doesn’t get any closer to an explanation than anyone else I’ve read, but he describes the phenomenon fantastically well.

One quick analytics lesson

Yesterday I saw an interesting link on Daring Fireball to a study that reported the results of searching for 2028 cities and towns in Ontario in the new iOS 6 Maps app for which Apple has apologized. Unsurprisingly, the results of the searches were not very good.

The first question that sprang to my mind when I read the piece, though, was, “How good are the Google Maps results for these searches?” Not because I thought Google’s results would be just as bad, but because looking at statistics in isolation is not particularly helpful when it comes to doing useful analysis. Obviously you can look at the results of the searches and rate the Apple Maps versus reality, but rating them against their competitors is also important. What should our expectations be, really?

Marco Tabini dug into that question, running the same searches under iOS 5.1 (running the Maps app that uses Google’s data). He found that the old Maps app does not outperform the new Maps app by a wide margin, and some interesting differences in how Apple and Google handle location searches.

This isn’t an argument that people shouldn’t be mad about the iOS 6 Maps search capabilities or lack of data, but rather that useful comparisons are critical when it comes to data analysis. That’s why experiments have control groups. Analysis that lacks baseline data is particularly pernicious in cases when people are operating under the assumption that they already know what the baseline is. In these cases, statistics are more likely to actually make people less informed.

Columnist Jon Carroll explains the Well

The Well does not own your words

San Francisco Chronicle columnist and long-time Well member Jon Carroll attempts to explain The Well. If you’ve ever been curious about it, now is a great time to join.

Why Web developers should care about analytics

I’m pretty sure the universe is trying to teach me something. For as long as I can remember, I’ve been dismissive of Web analytics. I’ve always felt that they’re for marketing people and that, at least in the realm of personal publishing, paying attention to analytics makes you some kind of sellout. Analytics is a discipline rife with unfounded claims and terrible, terrible products, as well as people engaging in cargo cultism that they pretend is analysis. Even the terminology is annoying. When people start talking about “key performance indicators” and “bounce rate” my flight instinct kicks in immediately.

In a strange turn of events, I’ve spent most of this year working in the field of Web analytics. I am a huge believer in making decisions based on quantitative analysis but I never connected that to Web analytics. As I’ve learned, Web analytics is just quantitative analysis of user behavior on Web sites. The problem is that it’s often misunderstood and usually practiced rather poorly.

The point behind this post is to make the argument that if you’re like me, a developer who has passively or actively rejected Web analytics, you might want to change your point of view. Most importantly, an understanding of analytics gives the team building for the Web a data-based framework within which they can discuss their goals, how to achieve those goals, and how to measure progress toward achieving those goals.

It’s really important as a developer to be able to participate in discussions on these terms. If you want to spend a couple of weeks making performance improvements to your database access layer, it helps to be able to explain the value in terms of increased conversion rate that results from lower page load time. Understanding what makes your project successful and how that success is measured enables you to make an argument for your priorities and, just as importantly, to be able to understand the arguments that other people are making for their priorities as well. Will a project contribute to achieving the overall goals? Can its effect be measured? Developers should be asking these questions if nobody else is.

It’s also important to be able to contribute to the evaluation of metrics themselves. If someone tells you that increasing the number of pages seen per visit to the site will increase the overall conversion rate on the site, it’s important to be able to evaluate whether they’re right or wrong. This is what half of the arguments in sports statistics are about. Does batting average or on base percentage better predict whether a hitter helps his team win? What better predicts the success of a quarterback in football, yards per attempt or yards per completion? Choosing the right metrics is no less important than monitoring the metrics that have been selected.

Finally, it often falls on the developer to instrument the application to collect the metrics needed for analytics, or at least to figure out whether the instrumentation that’s provided by a third party is actually working. Again, understanding analytics makes this part of the job much easier. It’s not uncommon for non-developers to ask for metrics based on data that is extremely difficult or costly to collect. Understanding analytics can help developers recommend alternatives that are just as useful and less burdensome.

The most important thing I’ve learned this year is that the analytics discussion is one that developers can’t really afford to sit out. As it turns out, analytics is also an extremely interesting problem as well, but I’ll talk more about that in another post. I’m also going to revisit the analytics for this site, which I ordinarily never look at, and write about that as well.

Older posts Newer posts

© 2024 rc3.org

Theme by Anders NorenUp ↑