All Things Distributed

There will be lots of stories remembering Al Shugart as “Uncle Al”; these stories will be filled with love and fun, and lots of good laughter. They will portrait Al as a good natured loving mentor and an unconventional industry maverick, but there was so much more to this man.

We also have to remember that it wasn’t just the love and fun that brought Al Shugart to the absolute top of the computer industry. Al was a fearless leader, very, very smart, with a deep understanding of the storage industry and the needs of its customers. He created a company that took the number one position from IBM in the eighties and maintained that ever since. In the fiercely competitive storage market that must mean something. Anyone worth its grain of salt in storage wanted to work for Al, as he would seriously invest in you to make you grow. Al strongly believed in roaming the engineer’s workspaces to keep in contact with the real world. Many Seagate customers still carry his personal phone number to “call any time with any question”. In the end there was the “revenge of the MBA’s” and Seagate was streamlined into a fast and efficient production machine, with Al looking on from afar.

From his autobiography, when discussion his advise to leave your car radio off while commuting, such that you would have some time to think:

Everybody needs thinking time. It helps balance your life. That’s one reason I don’t carry a laptop computer. When I go on trips it’s depressing to see everybody in the first-class sectionpecking away at their keyboards, searching obsessively for that last little kernel of information. They remind me of chickens in a barnyard scurrying after chicken feed
“What are you doing?”
“I’m checking my email.”
Right. As though that e-mail won’t be waiting for you when you get to your hotel. It’s sick. Why not relax in your seat, have a glass of wine and think.
Thinking is one of the great pleasures of being human and despite the fears of some futurists it won’t be usurped by computers. They are machines, that’s all. Good at mechanical tasks, but devoid of emotion. As a wise person once said: “asking if a computer can think is like asking if a submarine can swim”.

Al published 3 books: one autobiography, one about his attempt to let his dog run for congress (he hated bureaucracy) and one about his restaurant adventure with Piere Bain.

Posted by Werner Vogels at 9:39 AM | Permalink | Comments (1) | TrackBacks (0)

In the fine grained services approach that we use at Amazon, services do not only represent a software structure but also the organizational structure. The services have a strong ownership model, which combined with the small team size is intended to make it very easy to innovate. In some sense you can see these services as small startups within the walls of a bigger company. Each of these services require a strong focus on who their customers are, regardless whether they are externally or internally. To ensure that a service meets the needs of the customer (and not more than that) we use a process called “Working Backwards” in which you start with your customer and work your way backwards until you get to the minimum set of technology requirements to satisfy what you try to achieve. The goal is to drive simplicity through a continuous, explicit customer focus.

The product definition process works backwards in the following way: we start by writing the documents we'll need at launch (the press release and the faq) and then work towards documents that are closer to the implementation.

The Working Backwards product definition process is all about is fleshing out the concept and achieving clarity of thought about what we will ultimately go off and build. It typically has four steps:

1. Start by writing the Press Release. Nail it. The press release describes in a simple way what the product does and why it exists - what are the features and benefits. It needs to be very clear and to the point. Writing a press release up front clarifies how the world will see the product - not just how we think about it internally.
2. Write a Frequently Asked Questions document. Here's where we add meat to the skeleton provided by the press release. It includes questions that came up when we wrote the press release. You would include questions that other folks asked when you shared the press release and you include questions that define what the product is good for. You put yourself in the shoes of someone using the product and consider all the questions you would have.
3. Define the customer experience. Describe in precise detail the customer experience for the different things a customer might do with the product. For products with a user interface, we would build mock ups of each screen that the customer uses. For web services, we write use cases, including code snippets, which describe ways you can imagine people using the product. The goal here is to tell stories of how a customer is solving their problems using the product.
4. Write the User Manual. The user manual is what a customer will use to really find out about what the product is and how they will use it. The user manual typically has three sections, concepts, how-to, and reference, which between them tell the customer everything they need to know to use the product. For products with more than one kind of user, we write more than one user manual.

Once we have gone through the process of creating the press release, faq, mockups, and user manuals, it is amazing how much clearer it is what you are planning to build. We'll have a suite of documents that we can use to explain the new product to other teams within Amazon. We know at that point that the whole team has a shared vision on what product we are going the build.

Posted by Werner Vogels at 1:42 PM | Permalink | Comments (1) | TrackBacks (1)

Today was a good news day: Geoff Arnold has decided to join the Amazon engineering family. As Geoff mentions in the announcement on his weblog Amazon is all about scale. In recent presentations I have been demonstrating how Amazon Engineers are scalability experts who can take any concept idea and turn it into a service that can serve hundreds of customers and then grow it seamlessly to support hundreds of millions of customers. In the Amazon world there is no such thing as a limited beta; everything needs to be production quality when it launches and scale in every possible dimension. Incremental scalability is a key fundamental concept in all of our designs such that we can handle growth reliably and cost-effectively.

Posted by Werner Vogels at 6:08 PM | Permalink | Comments (1) | TrackBacks (0)