Another lesson we've learned is that it's not only the technology
side that was improved by using services. The development and
operational process has greatly benefited from it as well. The services
model has been a key enabler in creating teams that can innovate
quickly with a strong customer focus. Each service has a team
associated with it, and that team is completely responsible for the
service—from scoping out the functionality, to architecting it, to
building it, and operating it.

There is another lesson here: 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.

On idea development

If an idea is deemed worthy of investigation, we exploit our service development approach to scope and prototype the idea quickly.
With a new radical service, you try to go into prototype mode pretty
quickly, and then you start iterating on that until you feel that you
understand your business problem. The small-team concept means that you
have a continuous feedback loop where you try to understand the impact
for the customer.

That's in general how requirements are being refined, with the
customer in the loop. It is also very important to try to determine at
the outset what the success criteria should be, and how they can be
measured.

This fast response to new ideas is enabled through the loosely
coupled services model, both in technology and at the developer and
operations level. From the outside, the services in our platform may
appear chaotic, but chaotic in a good sense—in that we try not to
impose a rigid structure on the different functional pieces, but we
expect there to be order when looking at it from a different dimension.
Thinking about this whole system as a big deterministic system would be
unrealistic. Life is not deterministic, and a large-scale distributed
system such as Amazon has many organic and emerging properties that can
come to life only if you do not constrain it.

The Web 2.0 Show has an interview with David Heinemeir Hansson from 37 Signals that is full of great insights about his approach to programming and how he came to produce Basecamp and Rails.It's interesting that David initially came to development through PHP and later on Java and his choice of Ruby and the subsequent development of Rails was as a result of his dissatisfaction with both languages.

In the interview he covers how the Model-View-Controller (MVC) can reduce the complexity of an application and the benefits of how logic should happen in the smallest units possible so you can unit test a single method at a time.

I just finished listening to Tom Coates Native to a Web of Data talk from The Future of Web Apps Carson Workshop and viewing the slides from his presentation. I think this is a seminal piece of work which seems to perfectly capture the key issues that all web developers should be thinking about at the moment (what Matt Biddulph describes as the renaissance in web thinking). He summarises the issues as:

Link: Mozilla DOM inspector | clagnut/blog.The DOM Inspector looks like an obvious candidate for the enterprise standards web development toolbox.I've had a quick look at it in Firefox and it's going to take a bit of investigation to find out how to make best use of it.There are some further links around that explain a bit more about how it works.

del.icio.us direc.tor is a prototype for an alternative web-based rich UI for del.icio.us. It leverages the XML and XSL services of modern browsers to deliver a responsive interface for managing user accounts with a large number of records.