Werner Vogels in the ACM Queue on Amazon's Tech Platform

Tech: I ran across an interesting interview of Werner Vogels, CTO of Amazon, in the ACM Queue called A Conversation with werner Vogels. The interview covers a lot of terrain regarding Amazon's technology platform. One interesting aspect of development at Amazon, is that their developers actually operate their systems and are tightly intertwined with the end customers. Vogels states:

Giving developers operational responsibilities has greatly enhanced the quality of the services, both from a customer and a technology point of view. The traditional model is that you take your software to the wall that separates development and operations, and throw it over and then forget about it. Not at Amazon. You build it, you run it. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service.

The idea is intriguing. The wall Vogel mentions is high, and expensive - layers of project management, ops teams, etc all abstract developers away from truly understanding what needs to be done to enhance the end consumer experience. One problem though: how do you get great developers if you tell them they need to be on a 24/7 pager.

Another interesting angle is the freedom Amazon gives their developers. Here's a snippet:

I think part of the chaotic nature—the emerging nature—of Amazon's platform is that there are many tools available, and we try not to impose too many constraints on our engineers. We provide incentives for some things, such as integration with the monitoring system and other infrastructure tools. But for the rest, we allow teams to function as independently as possible. Developers are like artists; they produce their best work if they have the freedom to do so, but they need good tools. As a result of this principle, we have many support tools that are of a self-help nature. The support environment around the service development should never get in the way of the development itself.